Laggy input with long strings in Windows + Chrome + AMD/ATI GPU

[martinml]

Some users were reporting laggy input when typing long strings in a textarea with Autosize. I could never reproduce so I blamed buggy extensions or people connecting to the Internet with their toaster and whatnot.

But I started reviewing reports and found a possible connection: they all have ATI graphics and use Chrome in Windows. I borrowed a laptop with ATI graphics from a friend and this is what I saw (Chrome 49):

I've found it to be slow in these computers (60-175 ms spent in resize()):

• Windows 10, Intel P7350, ATI HD 4500
• Windows 10, Intel i5-3570K, unknown ATI GPU
• Windows Server 2008 R2, AMD N54L, ATI HD 4200
• Windows 10, Intel i5-750, ATI HD 7850

But not in these (0-10 ms spent in resize()):

• Windows 10, Intel i5-4670, Intel HD 4600
• OSX 10.11.4, i7-2600, ATI HD 6970M

Disabling GPU acceleration with --disable-gpu doesn't seem to change anything.

Here is a jsfiddle so you can test: https://jsfiddle.net/9ukLL4xo/

Possibly related: #241, #99

[jackmoore]

That's interesting. Thank you. I realize that the way autosize currently works is inherently expensive, but I'm doubtful much can be done about it outside of switching to another method (such as using a mirrored textarea element offscreen) or replacing the textarea element with a content-editable element. I moved away from using a mirrored element because difficult to efficiently guarantee an accurate size, though that method works fine for the majority of sites/stylesheets.

I made autosize as something that would be easy for other people to use, but I personally would probably attempt to use a content-editable element to avoid needing a script to do the resizing. I'm familiar with the issues of trying to turn content-editable into a WYSIWYG editor, but it seems like it would be adequate textarea replacement for plain text.

[jackmoore]

Github uses a mirrored textarea element for their comment textarea resizing, which is a lot easier to get right when you have control over the CSS. There could be some issue with content-editable they know about, since they go through the trouble of resizing a textarea element.

[martinml]

Thank you for your reply and your work!

I understand that you don't really have control over whatever Chrome internals go crazy after you change the height of the textarea. Especially when it's something so specific like this. My motivation to open this bug was half documenting it in case it was useful to someone else and half finding somebody that could at least confirm what I'm seeing.

I will study the mirrored textarea method, it should work better for my case. I don't really see contenteditable as a solution since I need it to be plain text and disallow any kind of format, and at the moment only Webkit supports the plaintext-only attribute. They do that on Disqus, for example.

[hemp]

Thanks @martinml for documenting; hitting the same issue and want to force the user to keep plaintext. Did you find a workaround? I'm going to try going back to version 1.18.18 to see how that profiles.

[martinml]

@hemp I'm using a mirrored textarea and didn't have more reports of laggy typing. It seems to be a better method but as @jackmoore said, you have to tailor it for your site.

In few words, I clone the original textarea to somewhere positioned outside the screen and make sure the content of both of them are in sync. Then I set the height of the original to the scrollHeight of the clone.

I'm still evaluating but it seems the way to go.