Re: [whatwg] Canvas in workers

Le 14/10/2013 01:27, Robert O'Callahan a écrit :
> On Sun, Oct 13, 2013 at 6:07 PM, David Bruant <bruant.d@gmail.com 
> <mailto:bruant.d@gmail.com>> wrote:
>
>     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();
>
>
> Two frames get queued as eligible for presentation. Which ones reach 
> the screen is unspecified of course.
Is there a way to know if/when a frame reaches the screen? Wouldn't this 
information be useful at least to know when it's safe to commit again?

Not directly related, but I imagine requestAnimationFrame doesn't work 
in a worker. How can a script know when to stop drawing on a given canvas?

>
>
>         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.
>
>
> What other reasons are there?
Won't there ever be?

>
>     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.
>
>
> I don't see this as being a problem, or at least no more of a problem 
> than it already is.
What do you mean by "than it already is"? Currently, if one calls a 
method on a context2d, the result is guaranteed to appear on screen 
eventually, no? It never happens that you start drawing and all of it 
gets dropped because of external conditions, right?

>
>
>         Of course it's OK for DOM API implementations to change state :-).
>
>     I don't understand what you mean here.
>
>
> It's OK for calling DOM methods to change state visible to script.
That's not the problem. The semantics of commit is "send this frame and 
maybe change dimensions". It's an awkward semantics mixing largely 
unrelated things.
It's like if the send() method of a worker's XHR didn't work when the 
<base> changed in the parent page. It's also very dependent on timing 
and may cause bugs that are very hard to debug.

David

Received on Sunday, 13 October 2013 23:55:29 UTC