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
case:
// draw things
wc.commit();
// draw other things
wc.commit();
?
I feel fairly strongly against the run-to-completion violation as
it's a foundation of how JavaScript works, how people reason about
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?
David
