#1499 Ticket comment textarea typing is slow when viewing, faster when editing
To reproduce:
- view a ticket and start typing a new comment. The text appearing is 3-4 characters behind what I have typed.
-
put the ticket into 'edit' mode, and start typing a comment in the same text area field. The display speed is fine, and matches the characters typed.
-
I also noticed slowness when creating a new ticket and typing in the description field, but it seems only on the first line of text. Once the area had expanded at least once, the response time sped up.
I wonder if Kyle's enhancements in this area to SFPY would help.
I can't seem to replicate the slowness at the moment, but I'm not crazy. I know I saw it, sigh.
Either way, the throttling/bouncing changes made to SFPY can't hurt, because even as I type this and it seems to be going ok, my CPU is bouncing around 50%, which isn't really acceptable given that all I'm doing is typing some text.
As of about five days ago (when I closed https://sourceforge.net/p/allura/tickets/1489/) we should be using the same jQuery plugin as SFPY. I ended up not doing any throttling/debouncing for the time being because the CSS changes took care of most performance issues. Allura might be a bit harder as there are more containers in play. It's something we need to watch out for: the more parent elements that a resizable textarea is wrapped in, the more parts of the DOM that are impacted by the resizing, the more CPU cycles required for the resizing. Throwing in multiple shadows, translucent backgrounds, and other CSS3 fun only makes the situation worse.