Forgot your password?
typodupeerror

Comment: Not always. Some LCD's refresh realtime (2ms lag) (Score 1) 139

by mdrejhon (#45174065) Attached to: NVIDIA's G-Sync Is VSync Designed For LCDs (not CRTs)

High speed video of an LCD refresh occuring in real-time:
http://www.youtube.com/watch?v=hD5gjAs1A2s

Also, input lag is the whole chain, INCLUDING how long it takes to display.
See AnandTech's article:
http://www.anandtech.com/show/2803/7

CRT's are only zero input lag at the top edge of the screen.
CRT's even have input lag for the bottom edge of the screen, because they have a finite frame transmission time (scanning from top to bottom).
Some gaming LCD's (certain BENQ and ASUS gaming LCD's) are the same way; they scan the pixels top to bottom in real time too (as seen in high speed video).

We're talking about input lag from game engine to human eyeballs, so it WILL also include frame transmission time (From computer to display), including any display mechanisms (scanout). nVidia G-Sync solves the problem by using ultrafast frame transmission times (1/144sec, even when running at 60Hz, since G-Sync uses a dotclock for frame transmission/scanout times of 1/144sec) -- they clearly explained it in their video.

Now, strobing does add a minor input lag, but an average of less than one frame. (For LCD's with less motion blur than CRT"s, google "lightboost" -- John Carmack said he uses a LightBoost monitor)

Comment: HIGH SPEED VIDEO of an LCD refreshing -- YouTube (Score 1) 139

by mdrejhon (#45174035) Attached to: NVIDIA's G-Sync Is VSync Designed For LCDs (not CRTs)

Hello,

Here's a high speed video of an LCD refreshing:
http://www.youtube.com/watch?v=hD5gjAs1A2s

This includes regular LCD refreshing modes, as well as motion-blur-eliminating LightBoost strobe backlight modes (that allows LCD to have less motion blur than some CRT's).

Mark Rejhon
Chief Blur Buster

Comment: Re:PWM - quite annoying for me, but no headaches (Score 1) 532

by mdrejhon (#44068179) Attached to: Ask Slashdot: Does LED Backlight PWM Drive You Crazy?

Interesting vision sensitivities. I have the same sensitivity to PWM trails --

Out of curiousity, do you prefer CRT or LCD?
What about 120 Hz LCD's with motion-optimized-strobe-backlights (google "LightBoost") which simulate a 120Hz CRT and perfect zero motion blur?

Comment: 120Hz PWM on 120Hz monitors (LightBoost): CRT like (Score 1) 532

by mdrejhon (#44068001) Attached to: Ask Slashdot: Does LED Backlight PWM Drive You Crazy?

For those people who don't mind CRT's, but get eyestrain from motion blur instead, there's a new technology called LightBoost (google "LightBoost") which is essentially PWM at one strobe per refresh, with 92% less motion blur than regular 60Hz LCD (full order of magnitude less motion blur).

Competition gamers have been purchasing 120Hz computer monitors as of late, and enabling the LightBoost strobe backlight, to regain CRT like clarity; covered at the Blur Busters Blog - http://www.blurbusters.com/ -- which also has 60Hz versus 120Hz versus LightBoost comparisions available.

And TFTCentral's "Motion Blur Reduction Backlights Including LightBoost":
http://www.tftcentral.co.uk/articles/motion_blur.htm
They found that LightBoost greatly outperformed scanning backlights.

Obviously, this technology is not for flicker sensitive people, but it can be turned on/off, and it's another option on the market.

Comment: True -- I agree, 10,000Hz flicker is detectable (Score 1) 532

by mdrejhon (#44067969) Attached to: Ask Slashdot: Does LED Backlight PWM Drive You Crazy?

This is true, 10Khz is detectabable, agreed by this paper
- http://www.lrc.rpi.edu/programs/solidstate/assist/pdf/AR-Flicker.pdf (10,000 Hz detected)

The last one has a rather interesting diagram where PWM, in certain cases, up to 10,000Hz, is detected via a stroboscopic / phantom array effect (not too different from wagon wheel effect).

Comment: Flicker up to 10,000Hz sometimes detectable (link) (Score 1) 532

by mdrejhon (#44067965) Attached to: Ask Slashdot: Does LED Backlight PWM Drive You Crazy?

You ideally need PWM >10000 Hz.

- http://opensiuc.lib.siu.edu/cgi/viewcontent.cgi?article=1538&context=tpr (500 Hz detected)
- http://www.lrc.rpi.edu/programs/solidstate/assist/flicker.asp (300 Hz detected)
- http://www.lrc.rpi.edu/programs/solidstate/assist/pdf/AR-Flicker.pdf (10,000 Hz detected)

The last one has a rather interesting diagram where PWM, in certain cases, up to 10,000Hz, is detected via a stroboscopic / phantom array effect (not too different from wagon wheel effect).

Comment: Re:first world problems (Score 1) 532

by mdrejhon (#44067955) Attached to: Ask Slashdot: Does LED Backlight PWM Drive You Crazy?

The best implementation is called LightBoost -- PWM at one strobe flash per refresh, for the CRT effect
http://www.blurbusters.com/faq/60vs120vslb (60Hz versus 120Hz versus LightBoost).

Also TFTCentral's "Motion Blur Reduction Backlights Including LightBoost" article:
http://www.tftcentral.co.uk/articles/motion_blur.htm

Comment: Standard is also designed for deaf people too (Score 1) 106

by mdrejhon (#36703544) Attached to: Real-Time Text Over Jabber/XMPP/Google Talk

It is feature that is partially targetted to the deaf, too. The spec introduction even explains benefits for the deaf:
http://xmpp.org/extensions/xep-0301.html [xmpp.org]
"Real-time text is text that is sent as it is created. The recipient can watch the sender type "as written words are typed" – similar to a telephone conversation where one listens to a conversation "as words are spoken". It provides a sense of contact in conversation, eliminates waiting times found in messaging, and is also favored by the deaf who prefer text conversation. For a visual animation of real-time text, see RealJabber.org [1]."

Comment: Re:Keys are buffered to keep transmissions reasona (Score 1) 106

by mdrejhon (#36696750) Attached to: Real-Time Text Over Jabber/XMPP/Google Talk

Oh -- and Google does not capture all messages.
There's lots of hidden XMPP message transmissions that goes on for other things, and Google does not log those.

XEP-0301 is intentionally designed to be backwards compatible, so you can safely transmit real-time text to any XMPP chat software, and it just ignores the real-time text part. It just displays only the finished (completed) messages. Though section 5 of the XEP-0301 spec recommends that you detect whether the remote end supports the real-time text, and to avoid transmitting real-time text, in order to save network bandwidth.

So existing software without real-time would work fine, even when connected to a real-time capable client that's intentionally transmitting real-time messages. (they're ignored since it's an additional XML element that's ignored, and only the finished full line of messages are displayed)

Comment: Re:Keys are buffered to keep transmissions reasona (Score 1) 106

by mdrejhon (#36696610) Attached to: Real-Time Text Over Jabber/XMPP/Google Talk

It wouldn't be difficult for Google to add it to Google Talk (unobtrusively, turned off by default)...

It works on Google Talk's network already via third party software. Thus, no XMPP server modifications needed.

An example is RealJabber experimental demo chat software whose source code I posted at http://realjabber.googlecode.com/ ... I tested XEP-0301 real-time over google's XMPP severs (gmail.com / talk.L.google.com) ... Google was able to handle up to more than 10 XMPP messages per second very easily, but XEP-0301 limits it to a recommended setting of just 1 XMPP message per second maximum, to be gentle on the network. (In fact, that's probably comparable to text-happy kids who say "Hi" "wassup" "u?" and type those messages once a second before transmitting them -- ha ha -- annoying to our group, but the XMPP network clearly can handle a protocol that requires a once-a-second message rate.)

I am working with several parties that are creating clients for Android as well as in AJAX/JavaScript (Linux/Android/iPad compatible). To prevent annoying users, Google could keep it turned off by default, but just an on/off menu item or button. Turning on/off real-time text like turning on/off audio or video. (It shouldn't be annoying as Google Wave that way, yet provide an important service for deaf people like me, and for people who *do* feel like turning on the feature -- even 1% or 10% is still a lot of people).

In fact, some existing chat software sometimes have real time text already (AOL AIM's "Real Time IM" -- a feature that is turned off by default and is a feature usually not discovered by most non-deaf people. Unfortunately, it is proprietary, unlike the open XEP-0301 protocol that anyone can use over Jabber/XMPP.)

P.S. You can't believe how some of us deafies are stuck with older technologies. For example, our text telephones (TDD / TTY) run at 45 baud! (Yes. 45. that's slower than 300 baud -- don't believe me? -- see http://en.wikipedia.org/wiki/TDD/TTY ..)

Comment: Keys are buffered to keep transmissions reasonable (Score 1) 106

by mdrejhon (#36694790) Attached to: Real-Time Text Over Jabber/XMPP/Google Talk

Actually, the spec does a compromise to transmit only 1 packet per second, even if there's 10 key presses per second.
It buffers the key presses for a full second, even including the original intervals between the key presses.
Then it transmits XML for the whole sequence, all at once.

This avoids overloading the network with too many messages per second, while keeping it sufficiently real-time, in a balanced compromise. (Yes, I know, it's "inefficient" XML, but XMPP.org encourages ease of programming over bandwidth efficiency. I'm fine with that. Besides, it doesn't really use much total bandwidth, anyway, especially since XMPP now permits base64 transmissions of avatar images and file transfers, etc -- all of which use more bandwidth than real time text. And the capped message rate is very reasonable.)

As this spec is partly designed for use by deaf people (including me; the specification's introduction specifically mentions this assistive use, too.), it is very desirable to see the original delays between the key presses. There is an animation of the key press interval encoding:
http://www.marky.com/realjabber/real_time_text_demo.html
As you notice in the animated GIF in the above link, there is a slight 'emotion' in the keypresses (calm typing versus panicked/emphatic typing) that deaf people like to pick up on, when supplemented with other contextual cues (text content, emoticons, etc).

Note -- For everyone else, the real-time feature can be turned on/off like audio/video is already an on/off feature in chats.

Comment: Good answer. (Score 1) 106

by mdrejhon (#36694568) Attached to: Real-Time Text Over Jabber/XMPP/Google Talk

Good answer.

Some interesting notes to add, for this technology:
-- It's also allowed to use a different transmission interval (i.e. 300ms) to reduce the lag, especially if you're using your own XMPP network where you can control the servers, etc. If using your own LAN XMPP server, you could even turn off transmission buffering and transmit all changes/keypresses immediately, but that's not a good idea for the public XMPP network, since that means 30 XMPP messages a second for a key being held down (auto-repeat)
-- Generally, instead of capturing keypresses, an even better method is to monitor for text changes instead.
This is because of the need to capture copy/pastes, automatic text replacements (auto spell checkers), voice recognition systems, special keyboards, that might not output one keypress at a time. Everytime the text in the sender's message changes, scan for the change (which is done in EncodeRawRTT( ) line 315 in RealTimeText.cs in realjabber.googlecoe.com ...) and generate the action elements that way. That way you capture all possible changes to the text, as generally recommended in Implementor's Notes in section 6.2.1 of the specification. Although keypress events are OK, if you can strictly control all other possible changes to text (i.e. alternative text entry methods, copy/pastes, etc)

Comment: The feature can be turned on/off. (Score 1) 106

by mdrejhon (#36694362) Attached to: Real-Time Text Over Jabber/XMPP/Google Talk

The spec is actually more targetted towards deaf-friendliness. The spec mentions:
"Real-time text is text that is sent as it is created. The recipient can watch the sender type "as written words are typed" – similar to a telephone conversation where one listens to a conversation "as words are spoken". It provides a sense of contact in conversation, eliminates waiting times found in messaging, and is also favored by the deaf who prefer text conversation. For a visual animation of real-time text, see RealJabber.org [1].

That said, it's useful in the enterprise in certain contexts like an assistive-friendly workplace that does not involve boss chats, and also between two different engineers who intentionally turn on the feature (which is an on/off feature, like audio can be turned on/off and video can be turned on/off). In your use case, you definitely want to turn this feature off.

Comment: Response to time-based smoothing alternatives. (Score 1) 106

by mdrejhon (#36694244) Attached to: Real-Time Text Over Jabber/XMPP/Google Talk

Yep, that worked, and it works well.
In fact, XEP-0301 mentions that an alternate smoothing method can be used as an alternative in the last bullet of Section 6.2.3.

However, because this standard is designed to benefit deaf people like me:
Some of us deafies are sensitive to 'emotion' in typing. People type differently when calm (smooth, typo free) or panicked (fast, lots of typos), or tired (slow, more typos). When we talk to the same person frequently, we can pick up the emotion partially from the typing, especially when supplemented with additional context (typed words, emoticons, etc). The spec encourages the use of high-precision transmission of delays in typing (Section 6.1.2), because that is more interesting than packet bursting (Section 6.1.1).

Time-based smoothing has the advantage of masking out typos especially if I do word transmission (giving the sender the opportunity to fix typos first). However, many deafies prefer seeing the original typing at high precision, for "maximum fidelity" of text-based communications.

The spec is being continually updated, to cover additional use cases, and this may be covered/clarified in a future update (since the spec is still in its Experimental stage, there is plenty of time to improve the spec; as XMPP.org gives every specification a mandatory minimum 12-month experimential period, before being upgraded to Draft status.)

"Life, loathe it or ignore it, you can't like it." -- Marvin the paranoid android

Working...