On Sun, Oct 13, 2013 at 12:12 PM, Glenn Maynard <gl...@zewt.org> wrote:
> On Sat, Oct 12, 2013 at 11:12 PM, Kyle Huey <m...@kylehuey.com> wrote: > > > 1. Rename CanvasProxy to WorkerCanvas and only allow it to be > > transferred to workers. I don't think we're interested in supporting > > cross-origin <canvas> via CanvasProxy (I would be curious to hear more > > about what the use cases are). > > > > You can transfer data to a worker that's cross-origin, if you have a > MessagePort where the other side goes to another origin's worker (possibly > given to you via eg. window.postMessage). > > Is the real goal here trying to limit this to threads and avoid IPC, or is > this actually a cross-origin concern? > Basically it's simpler to have CanvasProxy/WorkerCanvas only supported on workers. Cross-origin isn't itself a concern. > 2. Add a worker-only WorkerCanvas constructor that takes the desired > > width/height of the drawing surface. > > > > This looks like it's trying to allow entirely off-screen rendering within a > Worker, which is fine, but there's no way to resize the backing store in > this mode. > We don't have a use-case for resizing the backing store of a worker-created canvas. > simply draw in a loop without yielding. To solve this, if commit is > called > > and the current dimensions on the main thread don't match the dimensions > of > > the WorkerCanvas it would fail (return false) and update the dimensions > of > > the WorkerCanvas before returning. This is technically a violation of > > run-to-completion semantics, but is needed to support workers that do not > > yield. > > > > This sounds like it's easy to get wrong, since it'll probably be rare. An > exception might be better, so if you don't handle it you at least get an > error logged to the console. > Sure, that's probably better. There will be flicker issues with this. The canvas is cleared when you > change width or height. In the UI thread that's OK, since the author can > synchronously redraw immediately after changing the size. Here, it's > likely it won't be redrawn in time, so it'll flicker whenever the size > changes, especially if it's being changed smoothly. Here's a suggestion to > fix this: > > - When the UI thread changes Canvas.width or Canvas.height, it doesn't > actually resize buffers. Instead, it sends a message to the WorkerCanvas > asking for the change. Until the change actually happens, the Canvas > continues to be composited as before. (However, the change to .width and > .height is visible on the object immediately.) > - When the WorkerCanvas's event loop receives a message asking for a size > change: > - Change the size of the back-buffer, and update WorkerCanvas.width and > WorkerCanvas.height accordingly. > - Fire onresize on the WorkerCanvas. The worker is expected to redraw > here. (This is where the "implicit commit" matters: we want to guarantee a > commit here.) > - Only when the newly-redrawn buffer is committed does the front buffer's > size get updated to match the back-buffer. > > In other words, when you change the size in the UI thread, it continues to > composite the same image (possibly not filling the whole element, or being > stretched) until the worker actually gets the resize and has a chance to > redraw it. > > This also means the idea of not being able to commit because of a resize > can go away, and commit() can be void, since the back-buffer size never > actually changes while the worker is drawing. > There is the slight problem that changing both width and height would fire two events. A bigger problem is that your approach isn't compatible with a worker that draws frames in a loop without yielding. I'm uncertain how important that is, so I'll wait for Kyle to address that. Rob -- Jtehsauts tshaei dS,o n" Wohfy Mdaon yhoaus eanuttehrotraiitny eovni le atrhtohu gthot sf oirng iyvoeu rs ihnesa.r"t sS?o Whhei csha iids teoa stiheer :p atroa lsyazye,d 'mYaonu,r "sGients uapr,e tfaokreg iyvoeunr, 'm aotr atnod sgaoy ,h o'mGee.t" uTph eann dt hwea lmka'n? gBoutt uIp waanndt wyeonut thoo mken.o w * *