You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Web UI timeline performance it horrific when rendering a lot of tiny events.
The reason why is because SVG is being used to display them and there's clipping on every event to avoid text overflow.
SVG is cool and besides interactivity possibly causing some issues for Safari users, it's a much simpler solution than drawing stuff on the canvas.
But the overflow: hidden attribute prevents the browser from batch rendering which means that when there's (let's assume) 1000 2px-wide events, their text requires 1000 individual render calls and the one containing event grid has to wait for all of them which means each animation frame has to deal with a lot of render calls and produces textures that are basically discarded in the last pass due to padding. Browsers do parallelize these draw calls, but it's impossible to do it for 1000 components so this causes
a) a lot of pointless data transfers,
b) if 50 components are drawn in parallel, 1000/50 sequential draw calls.
A very simple solution to this is not displaying vis-item-overflow at all if it's width is smaller than vis-item-content padding. I'd personally skip it if vis-item-content is less wide than padding + 2ch too because 2ch is too little to be useful IMO.
Also, vis-item-content has transform: translateX(0);, not sure of this is intentional, but this introduces additional pipeline complexity for all 1000 of the invisible draw calls.
My suggestion is that events get grouped into groups based on their duration and that the timeline hides content of individual events at certain scales.
This can be achieved globally via CSS properties and classes to avoid huge DOM updates:
Names are verbose for clarity, better names should be used :)
With this approach, on zoom in/out, only the class of the timeline needs to be updated. The browser would then discard all 1000 draw calls instead of drawing and then cropping them into transparent 2px wide rects and trying to composit them together.
The text was updated successfully, but these errors were encountered:
Web UI timeline performance it horrific when rendering a lot of tiny events.
The reason why is because SVG is being used to display them and there's clipping on every event to avoid text overflow.
SVG is cool and besides interactivity possibly causing some issues for Safari users, it's a much simpler solution than drawing stuff on the canvas.
But the
overflow: hidden
attribute prevents the browser from batch rendering which means that when there's (let's assume) 1000 2px-wide events, their text requires 1000 individual render calls and the one containing event grid has to wait for all of them which means each animation frame has to deal with a lot of render calls and produces textures that are basically discarded in the last pass due to padding. Browsers do parallelize these draw calls, but it's impossible to do it for 1000 components so this causesA very simple solution to this is not displaying
vis-item-overflow
at all if it's width is smaller thanvis-item-content
padding. I'd personally skip it ifvis-item-content
is less wide than padding + 2ch too because 2ch is too little to be useful IMO.Also,
vis-item-content
hastransform: translateX(0);
, not sure of this is intentional, but this introduces additional pipeline complexity for all 1000 of the invisible draw calls.My suggestion is that events get grouped into groups based on their duration and that the timeline hides content of individual events at certain scales.
This can be achieved globally via CSS properties and classes to avoid huge DOM updates:
Names are verbose for clarity, better names should be used :)
With this approach, on zoom in/out, only the class of the timeline needs to be updated. The browser would then discard all 1000 draw calls instead of drawing and then cropping them into transparent 2px wide rects and trying to composit them together.
The text was updated successfully, but these errors were encountered: