[whatwg] Canvas in workers
bruant.d at gmail.com
Sun Oct 13 15:07:25 PDT 2013
Le 13/10/2013 23:33, Robert O'Callahan a écrit :
> bool commit();
> Boolean as return value for success? :-s
> A promise instead maybe? throw instead of false at least?
> In any case, it looks like commit could be a long operation (tell
> me if I'm wrong here. Do you have numbers on how long it
> takes/would take?), having it async sounds reasonable.
> "commit" does not need to be async, it doesn't have to block in practice.
Just so that I better understand how commit works, what happens in this
// draw things
// draw other things
> I feel fairly strongly against the run-to-completion violation as
> programs. Also, TC39 is working hard to close the gap between what
> can be expressed in pure ECMAScript and what the web platform does
> express, it'd be inappropriate to add things that widen this gap
> in my opinion.
> Personally I don't see this as a violation of run-to-completion
> semantics. The important thing is that the dimensions of the
> WorkerCanvas (and any other state observable by the worker) do not
> change except during the call to commit(). Effectively commit() itself
> performs the change.
Hmm... Interesting point of view...
That's the only way to learn that the dimensions have changed? Via
commit() throwing an error/returning false? It feels very ad-hoc. It
doesn't seem to scale very well to other reasons why commit() might fail.
I also imagine that the normal pattern will be "draw then commit", so it
means that you always spend efforts drawing without ever knowing if what
you're drawing is ever going to end up on screen; which feels like a
waste of resources.
> Of course it's OK for DOM API implementations to change state :-).
I don't understand what you mean here.
What happens to WorkerCanvas in the canvas element is removed from the
document or display:hidden-ed?
More information about the whatwg