Aurelia specific logic
Closed this issue · 4 comments
Can you please, explain why we need this long tsAfter = isAurelia ? tsEventFire : tsEvent; Thanks.
I want to measure the duration from the click to that point of time when the DOM has been updated. Please take a look at the attached picture:
On the left is the click event, then a pause of ~90 msecs, then the repaint happens. I want to measure the duration starting with the click event until the final repaint occurred which means ~110 msecs. Aurelia causes a first very short repaint after the click event and thus I must wait for the timer event and take the next repaint. Calculating it that way comes very close to the duration that is shown in the timeline.
This also means that this benchmark favors frameworks that perform an immediate dom update. Thus especially the tests that run very short must be taken with caution, especially for aurelia since the measured duration is not determined by the javascript duration, but by the idle time waiting for the timer.
Vidom is another framework that batches dom updates, but vidom has a much shorter pause and seems to be using RAF instead of a timer and it does not cause a repaint after the event handler. Here's a timeline screenshot for vidom:
Aurelia was the only framework that forced me to create such a hack (at least for Chrome 48).
So my question is: Why does the timer for aurelia fire with such a long delay? Why don't they use the next animation frame?
Thank you very much for the explanation. Sometimes when I run aurelia tests, the app throws exception saying that the last paint event is NULL. And the events ordering causes this ussue. It happens to be "EventDispatch" -> "PaintEvent" - "TimerFire" without another paint event afterwards. This happens rarely, if I run it 12 times it could appear in any of them or passes without exception. Is it appropriate to catch this exception and just ignore it as a workaround ? Thanks in advance
Looking at the code again I think it is no longer needed, since I changed the logic to take always the last paint. This was due to Chrome 49 which changed rendering and had paint events for other frameworks that were not shown in the timeline (and is quite a bit slower than Chrome 48).
But that doesn't really explain your exception. I've only seen such problems when the browser window was hidden or minimized. Ignoring the exception works but doesn't leave the good feeling of correctness. Is the browser window visible? What Chrome Version are you using?
Sorry for the late response. The problem still stands. I am using chrome v 50. The browser window is visible. Anyway, I made some changes to my particular case and it seems it is working. Thanks