Re: [w3ctag/design-reviews] Event Timing API (#324)

Some additional thoughts of mine:

* If performance metrics will be gathered from event types for which no event listeners are registered, as the proposal implies, then how is that data useful? E.g., a web site may not have registered any touch events, but the user is using their finger to manipulate the content… does the browser need to record the timing information for what might have happened if the touch events were dispatched?  

* Is the observer type 'events' too generic? UAs might prefer a more fine-grained event type (e.g., 'mouse-events') to cut-down on the perf impact that observing will have… 

* One assumption in the spec is that this timing data will be useful to help sites determine causal issues for slow events (that may be causing "smoothness" issues in the user experience). However, it might not be good to assume that there is always correlation between the hw timestamp of the UI event and the time that it is dispatched by the UA. For example, servicing multiple queues internally, animations running on the UI thread, decoding/encoding processes, web audio graph processing, etc., to say nothing of browser-external factors like limited memory conditions causing disk-swapping or page-faulting, or large numbers of open apps competing for CPU time by the OS scheduler. All of these things are happening and can lead to high variability in causality for slow events (especially in that time between received timestamp and dispatch). Setting a high bar for emitting the record (50ms) is one way to cut down on the noise, but it may not be sufficient. 

* In many of the scenarios, the standards performance metrics APIs (mark/measure) are seemingly insufficient because they don't capture the time before the resulting display update (if this assumption is wrong, please correct). I wonder how correlated the cause-and-effect of events to UI change/updates often is. For example, one scenario describes hovering a menu item that triggers a flyout. (We'll assume that this hover/flyout behavior is triggered by an onmouseover event handler, because CSS hover menus do not need script--would those be counted?) There may be an onmouseover event that run, but triggers asynchronous code that eventually causes the menu to appear--in this case, you've lost the causality relationship. I fear there are far too many of these kinds of scenarios in author code, that the metrics collected from these event timings would be useless. 

* Perhaps one way to improve the utility of this proposal would be to get more specific--just tracking all mousemoves (for example) may not be terribly useful or provide insightful data. However, if there is a particular element subtree that you are interested in observing the mouseover characterisitics, that it could be more interesting (because it is more specific). In this case, you want to be able to register for performance metrics for events in combination with an element, or perhaps layout box?

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/324#issuecomment-460882788