Basic Chart/Point Drawing Optimizations

[jeffpamer]

This PR does a couple things that I feel like are low-hanging fruit optimizations, and pretty "safe", i.e. shouldn't present any noticeable change relative to the current functionality. I'm interested to see after merging these in with @AaronPlave's zoom work what our baseline performance is, and then see where we need to go from there.

• Render the data points to an offscreen canvas and then copy them as image data as needed. This should be quite faster than redrawing new arc paths every time.
• Splits rendering the line and points into two separate frames. This has two advantages:
  1. Rendering the lines and points across separate frames means we give the main thread a chance to unblock in-between
  2. If we get several immediate requests to redraw the line, we can cancel the existing requests to draw the points and only draw them once at the end. Effectively debouncing them. If we want I think we could be even more aggressive about this, i.e. delay drawing the points until after 50ms pass from the original draw request.

[AaronPlave]

I get this when I load up a particular view - think it might be an issue with points with 0 size?

[AaronPlave]

Also I'm seeing this shape for the points on my machine

[duranb]

Also I'm seeing this shape for the points on my machine

Interesting...I'm not seeing that shape. Do you get that for a specific resource's plot or for all line charts? Also are you on a new m2 mac or intel?

[duranb]

@jeffpamer do you think we should wait until @AaronPlave's zooming work is done so that we can fully test this?

[jeffpamer]

I get this when I load up a particular view - think it might be an issue with points with 0 size?

Oh interesting, I didn't realize points could be zero size, I'll put in something to handle that ... likely just skip the point rendering entirely?

Do you think we should wait until @AaronPlave's zooming work is done so that we can fully test this?

I was thinking it would be good to get this merged in first and then Aaron could just pull it into his branch to test it out. But looks like there's a couple issues to sort out! I'll look into them but not sure if I'll have enough time to solve today.

[jeffpamer]

I might try to carve out some time while traveling next week to look into this more, but otherwise I'll just need to pick it up the week after!

[jeffpamer]

@AaronPlave @duranb sorry for the delay here but I think this should be patched up and ready to go, would you mind taking another look Aaron?

The gist of the problem is that you typically handle high resolution rendering by scaling up your canvas size and context scale factor by devicePixelRatio to draw in high resolution and then scale the canvas down to it's expected pixel size using CSS to get the expected result. But OffscreenCanvas doesn't support sizing by CSS, so instead what we need to do is scale up the canvas and draw at 2x size like usual, but then where we copy the image data over to the onscreen canvas, explicitly specify the size we want to draw each point in standard screen pixels.

A good little "a ha" moment for working with OffscreenCanvas

[AaronPlave]

LGTM. Does look like the drawImage performance + deferred rendering of these points does result in at least slightly better performance for a large collection of resource plots with many points.

[jeffpamer]

LGTM. Does look like the drawImage performance + deferred rendering of these points does result in at least slightly better performance for a large collection of resource plots with many points.

Cool good to hear, my hope would be the "perceived performance" would be the biggest benefit since the deferred rendering would give the main thread a chance to flush. We can also look into maybe tweaking exactly how long to delay the point rendering ...