In my experience, 4.0 scores much better than 3.5. It's the reason why I use Visual Studio Code plugins ("Genie AI") and a paid subscription to GPT 4.0 API. Much better AI-based pair programmer. Outputs more slowly but seems 10x smarter about code.

There was indeed some regressions in 4.0 but only ~10% closer to 3.5

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)

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

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?

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.

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).

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).

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

No, it has to be the same as refresh rate, or you get PWM artifacts:
http://www.blurbusters.com/faq/lcd-motion-artifacts

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]."

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)

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 ..)

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.

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)

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.