WICG / canvas-place-element

Other
58 stars 3 forks source link

OffscreenCanvas support? #2

Open mmocny opened 2 months ago

mmocny commented 2 months ago

Is there any plan to support OffscrenCanvas with these new apis?

My read is that the element being placed has to be a "direct child of the canvas element". I think this does limit the api to the main thread, since you cannot pass a reference to an element across to workers, and the OffscreenCanvas, although transferable, is not an element that would have access to the actual <canvas> children.

Is that correct?


I think it would be interesting to support some sort of (even limited) use case for Web workers, such as just supplying dynamic data for an html template / Web Component / DOM Parts, etc.

One of the uses cases I have could be summarized as:

Besides just moving the cost of the compute for props off the main thread, a requirement is to asynchronously display visual updates decoupled from the main thread animation frame rate. So just a convenience wrapper around postMessage is not sufficient for this use case.

Is it viable to consider something like this in the future? Or does it fundamentally require main thread?

Cheers.


(Apologies, I know I asked this question elsewhere but am failing to find the source now...)

schenney-chromium commented 2 months ago

I think you asked the question on the original proposal doc that was circulating.

Anyways, the issue is running style/layout/paint on the worker to determine the display list for the element. I suppose you could somehow pass that display list to the worker, but for the worker to do anything other than just draw it you would need a whole new parameterized display list concept (I think).