Item9427: WYSWIYG slow cursor movement on IEs
Current State: Closed
Released In: 1.1.0
Target Release: minor
Continued from Item9263
to address slow cursor movement in IE6, IE8 and probably IE7
The new formatter code is simpler but more CPU intense. The other browsers seem better able to optimise those loops whereas the IEs struggle. I have some ideas.
- 02 Aug 2010
Will not be able to get to this until after 14 Aug. Maybe a beta release is doable with this left unfixed if it's mentioned in the known issues.
- 03 Aug 2010
I will downgrade it to normal.
You need ridiculous large topics to see it and it is not killing the usage in those rare case. Just a little annoying.
- 19 Aug 2010
So only 3.6% slower than no button state magic at all, and 42% faster than always updating. On a larger document I expect the difference to be even greater.
The test topic was:
-- Main.PaulHarvey - 19 Aug 2010
The test methodology was:
- Iceweasel 3.6.7 on quad 3.0GHz amd64 Xeon
- Firebug 1.5.4
- Test topic as above, in edit
- Position cursor on first line
- Clear console
- In rapid succession (seems to improve repeatability):
- Start profiler
- Tap down arrow three times (to transition between three different formats)
- Stop profiler
- Do ~10 runs and take estimated median
- 20 Aug 2010
I will wait for feedback on the button state latency and how people think it affects the user experience. Setting to less than 500ms reduces the effectiveness this is supposed to bring when you really do have a slow PC/IE on a large document.
So it's trivial to make this configurable, and default to say 100ms latency; I'll wait and see.
- 20 Aug 2010
Kenneth suggested 200-300ms. Making this configurable from the
(no new pref vars; we need a setting that is good for 99% users). TODO: make the
take an array of callbacks that might be fired when cursor is idle
- 26 Aug 2010
Although this is on the plugin's release history, I didn't close this until after 1.1.1. Oops.
- 28 Oct 2010