Hi Devs,
I have a question about the benefits of the change from event based to polling based folder highlighting when dragging.
Revision 1763 changed the manner in which target folders are highlighted when dragging a message. Before 1763, each folder had an onmouseover which would trigger focus_folder.
1763 removed that onmouseover event and instead calls drag_move every time the mouse moves. drag_move essentially polls the position of the mouse and loops over every folder on screen to see if the mouse is above that folder folder. This polling is costly and has mixed effects across browsers, operating systems and pcs with different specs.
On all systems tested so far, even if the dragging appears smooth, at least one cpu is maxed at 100% by the polling. On some systems/browsers a cpu is pegged and the dragging is intolerably choppy and slow.
The commit comment for 1763 includes: "Don't rely on browser events anymore"
Is relying on browser events a bad thing? Worse than polling?
It seems that the previous highlighting detection method was more efficient and compatible across a wider range of systems.
If there are reasons that polling has to be the answer, then perhaps we can add some sort of rate limiting?
Thanks for your consideration, Ziba
On Wed, 01 Oct 2008 11:59:18 -0400, Ziba Scott ziba@umich.edu wrote:
1763 removed that onmouseover event and instead calls drag_move every time the mouse moves. drag_move essentially polls the position of the mouse and loops over every folder on screen to see if the mouse is above that folder folder. This polling is costly and has mixed effects across browsers, operating systems and pcs with different specs.
I must agree with you. It's slow and currenty (dragging) isn't working over preview panel's iframe. It must be fixed in some way, but it was Thomas' change, wait what he'll say.
A.L.E.C wrote:
On Wed, 01 Oct 2008 11:59:18 -0400, Ziba Scott ziba@umich.edu wrote:
1763 removed that onmouseover event and instead calls drag_move every time the mouse moves. drag_move essentially polls the position of the mouse and loops over every folder on screen to see if the mouse is above that folder folder. This polling is costly and has mixed effects across browsers, operating systems and pcs with different specs.
I must agree with you. It's slow and currenty (dragging) isn't working over preview panel's iframe. It must be fixed in some way, but it was Thomas' change, wait what he'll say.
i recently stumpled accros http://ppdrag.ppetrov.com/ maybe this is of interest.
cheers, raoul
Just coming back from the jQuery Camp 2008 in Boston and they plan to
improve dragging. So if RC is migrated to jQuery, why not use jQuery
UI as well?
What's the status on jquery usage?
lg, Mike
>> wrote: >> >>> 1763 removed that onmouseover event and instead calls drag_move
>>> every >>> time the mouse moves. drag_move essentially polls the position of
>>> the >>> mouse and loops over every folder on screen to see if the mouse is
>>> above >>> that folder folder. This polling is costly and has mixed effects
>>> across >>> browsers, operating systems and pcs with different specs. >> >> I must agree with you. It's slow and currenty (dragging) isn't
>> working over >> preview panel's iframe. It must be fixed in some way, but it was
>> Thomas' >> change, wait what he'll say. > > i recently stumpled accros http://ppdrag.ppetrov.com/ > maybe this is of interest. > > cheers, > raoul > -- > ____________________________________________________________________ > DI (FH) Raoul Bhatia M.Sc. email. r.bhatia@ipax.at > Technischer Leiter > > IPAX - Aloy Bhatia Hava OEG web. http://www.ipax.at > Barawitzkagasse 10/2/2/11 email. office@ipax.at > 1190 Wien tel. +43 1 3670030 > FN 277995t HG Wien fax. +43 1 3670030 15 > ____________________________________________________________________ > _______________________________________________ > List info: http://lists.roundcube.net/dev/ _______________________________________________ List info: http://lists.roundcube.net/dev/
Hi Ziba,
I have a question about the benefits of the change from event based to polling based folder highlighting when dragging.
I am not developing RC, but your question interested me. I presume that event-based highlighting might suffer from the fact that 'mouseover' and 'mouseout' events are fired each time cursor moves above target element _and any of its descendants_. This means that when you freely move above the target rectangle, many and many highlights/unhighlights might happen in the background (as you hover mouse above rectangle's children).
On the other hand, the "polling-based" approach can be relatively highly optimized (using pre-calculation of target rectangles coordinates, because getting .offset* properties is a very slow operation), resulting only in numerical computation (basicly no DOM interaction required).
Sincerely, Ondrej Zara, happy RC user :)
Revision 1763 changed the manner in which target folders are highlighted when dragging a message. Before 1763, each folder had an onmouseover which would trigger focus_folder.
1763 removed that onmouseover event and instead calls drag_move every time the mouse moves. drag_move essentially polls the position of the mouse and loops over every folder on screen to see if the mouse is above that folder folder. This polling is costly and has mixed effects across browsers, operating systems and pcs with different specs.
On all systems tested so far, even if the dragging appears smooth, at least one cpu is maxed at 100% by the polling. On some systems/browsers a cpu is pegged and the dragging is intolerably choppy and slow.
The commit comment for 1763 includes: "Don't rely on browser events anymore"
Is relying on browser events a bad thing? Worse than polling?
It seems that the previous highlighting detection method was more efficient and compatible across a wider range of systems.
If there are reasons that polling has to be the answer, then perhaps we can add some sort of rate limiting?
Thanks for your consideration, Ziba
List info: http://lists.roundcube.net/dev/
On Wed, Oct 1, 2008 at 18:10, A. L. E. C alec@alec.pl wrote:
On Wed, 01 Oct 2008 11:59:18 -0400, Ziba Scott ziba@umich.edu wrote:
1763 removed that onmouseover event and instead calls drag_move every time the mouse moves. drag_move essentially polls the position of the mouse and loops over every folder on screen to see if the mouse is above that folder folder. This polling is costly and has mixed effects across browsers, operating systems and pcs with different specs.
I must agree with you. It's slow and currenty (dragging) isn't working over preview panel's iframe. It must be fixed in some way, but it was Thomas' change, wait what he'll say.
The main reason to change this was Firefox which didn't fire the mouseover and mouseup event when the user started dragging on an empty part (no text below) of the message list. Mousemove events also got lost on the iframe with the old solution.
The new polling solution worked nice (and with the same results) on all the browsers I tested. Of course there's some potential for improvements like using intervals to do the collision detection and only set mouse coords in the event handler routine.
If you have suggestions to improve the dragging, don't hesitate to post them here. For the 0.3 version we're planning to use jquery and this will probably solve the issue anyway.
~Thomas _______________________________________________ List info: http://lists.roundcube.net/dev/
Thomas Bruederli wrote:
The main reason to change this was Firefox which didn't fire the mouseover and mouseup event when the user started dragging on an empty part (no text below) of the message list.
Firefox 3.0 fixes this issue
Mousemove events also got lost on the iframe with the old solution.
You're right. Didn't check previous version.
The new polling solution worked nice (and with the same results) on all the browsers I tested. Of course there's some potential for improvements like using intervals to do the collision detection and only set mouse coords in the event handler routine.
Not nice because it's slow and there are visible "jumps" even on newer PC.
Added ticket http://trac.roundcube.net/ticket/1485444
Thomas Bruederli wrote:
If you have suggestions to improve the dragging, don't hesitate to post them here. For the 0.3 version we're planning to use jquery and this will probably solve the issue anyway.
one thought that occurs to me: why are you spending time in updating this for 0.2 if it will change again for 0.3? :)
cheers, raoul
Raoul Bhatia [IPAX] wrote:
Thomas Bruederli wrote:
If you have suggestions to improve the dragging, don't hesitate to post them here. For the 0.3 version we're planning to use jquery and this will probably solve the issue anyway.
one thought that occurs to me: why are you spending time in updating this for 0.2 if it will change again for 0.3? :)
cheers, raoul
Good point, +1 for stopping working on 0.2 and fixing bugs there and instead focusing on 0.3 unless there are severe security issues. "Does not work smoothly on older machines" is not really security related ;)
Mike
-
A.L.E.C -
Michael Baierl -
Ondrej Zara -
Raoul Bhatia [IPAX] -
Thomas Bruederli -
Ziba Scott