163599 - Strange event handling & layout behaviour

Status: RESOLVED WORKSFORME

(Core :: DOM: UI Events & Focus Handling, defect)

Description

[Markus Hübner]

this is taken from the a newsgroup posting to n.p.m.performance.

---------
Why does incrementing a js variable stored in the window object, and writing 
it to window.status force events and layout to update quicker? hmmm sounds 
weird doesn't it? have a look at http://www.azure-online.com/azl/js/az_drag.js 
in the mouse_move handler.

if (!az_libs.browsertype.ie) window.status = az_moz_heartbeat++;

the above line of code seems to speed events and layout up (i.e. makes it not 
suck) (if you remove that line, and drag the window in a constant circle 
without stopping, the layout never gets done - asif Moz is waitng for updates 
to stop before reflowing - not good behaviour for event driven animation like 
dragging a window.) 
---------

Comment 1

[Markus Hübner]

Is this related to bug 163528?

Comment 2

[José Jeria]

Dragging around the window in 
http://www.azure-online.com/azl/widgets_test.html

result in the same way as in bug 163528.

Comment 3

[pieter theron]

at http://www.azure-online.com/azl/window_test_normal.html I do it the way 'it 
should be done' but event handling seem to stop reflow getting done

at http://www.azure-online.com/azl/window_test_workaround.html I increment and 
write to window.status a value stored in the window object called moz_heartbeat 
every time i receive a mousemove event. this seems to fix it and reflows the 
document.

Comment 4

[pieter theron]

it actually makes quite a nice test of coordination, see how long you can drag
the window without moz doing a reflow! :)

Comment 5

[pieter theron]

Ok, I've solved it.... by writing my code the 'correct' way.

It now works the same on I.E and Mozilla, with no funny status tricks needed. 
And I get 100+ frames per second on the drag window test (when I allow it to 
tax the browser and os).

The difference betwen I.E. and Mozilla is that Moz will try and do as many of 
the updates that you tell it to, even if this means cutting back on event 
handling.

(I actually now think this should be a feature and not a bug - and that we 
developers should write our code better ;) The fact is at the end of the day, 
Moz is doing more of the style updates that you request - just too many to have 
time for events)

Here is the solution :

have one datastructure like this:

var taxvalue   = 5   // this requested ratio between events and updates 
(specifies how much you want to tax your system, setting this to 0 gets you 
100% in processor usage and no events on moz, i.e it tries to service every 
event it gets)
var evtperupd  = 0;  // the current ratio between events and updates
var fps        = 60; // the current frames per second the browser can handle
var lastupdate = 0;  // when you last asked the browser to update 
style/position/whatever


Then whenever you get an event, do this:

var curtime = new Date();
var curtick = curtime.getTime(); 
var curdif  = curtick - lastupdate;
if (curdif > (1000 / fps))
{
   if (evtperupd > taxvalue)
   {
      fps++;
   } else if (evtperupd < taxvalue) {
      fps--;
   }
   evtperupd  = 0;
   lastupdate = curtick;
   
   // do your style update movement whatever here //

} else evtperupd++;
delete(curtime);

Its just an adaptive scheme that keeps the number of updates per event pinned 
to the value you specify while keeping track of how many frames per second your 
browser can handle.

there is a new demo here:
http://www.azure-online.com/azl/window_test_adapt.html

and 
http://www.azure-online.com/azl/window_test_adapt_show_fps.html

if you look at the last one you will see that events are always received 
because you only do updates while receiving events which I guess is the one 
line explanation for all this.

the demos have 'taxvalue' set to 2 - i.e if you have not received 2 events 
since last update, don't do the next one. setting taxvalue to 1 gives you about 
100 fps, setting it to 0 brings on the symptoms that this bug describes.

azurensces

Comment 6

[Boris Zbarsky [:bzbarsky]]

This basically looks like bug 157144

Comment 7

[Markus Hübner]

pieter, what is your feedback when trying with a recent trunk build?

Comment 8

[Pham]

.

Comment 9

[Martijn Wargers (dead)]

All the url's in this bug don't work anymore, they're gone. Is this still an issue?

Comment 10

[Markus Hübner]

As we no longer can verify this with a valid testcase I think we should mark this WFM.