[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Public WebGL] getContext multiple context language
On Fri, Feb 5, 2010 at 12:17 AM, Mark Callow <firstname.lastname@example.org> wrote:
> Kenneth Russell wrote:
>> If multiple rendering contexts are active, they all render to the same
>> canvas bitmap; they are not layered or otherwise isolated. Changes
>> made to the canvas bitmap with one context must be immediately visible
>> to any other active contexts on the canvas. The implementation must
>> manage synchronization issues associated with rendering with different
>> contexts to the same canvas.
> I repeat my previous objections.
>> Implicit synchronization is fraught with problems as I have stated many
>> times before during this discussion. Lack of explicit synchronization is a
>> nightmare for implementers (with the tangled web of checks between contexts
>> growing as each new context type is added) and will encourage developers to
>> interleave calls in ways that will be horrendously inefficient on any
>> hardware that is attempting parallelism, which these days is pretty much
> You previously wrote:
>> In earlier discussions it was stated that if the developer fails to
>> call waitContext() then incorrect or undefined rendering results will
>> occur. This will lead to nonportable behavior and I don't think it is
>> a good idea.
> The results will be incorrect on all implementations. Are you saying you
> want to have identical incorrect results across implementations?
I want the results to be repeatable, not specifically that the
identical incorrect behavior is produced.
>> If the synchronization checks occur in the implementation, their added
>> cost is a fetch from thread-local storage per rendering call. Such
>> checks already exist in the WebKit WebGL implementation and they are
>> nowhere near the top of the profile, at least at this point. I think
>> the synchronization among the various contexts should remain implicit.
> The more context types you add, the worse it gets. A separate
> has-something-been-drawn flag has to be checked for each context type. Some
> context types may have a large number of drawing commands, each of which
> must be modified to set the flag, if that context is to participate in
> simultaneous rendering.
It can be implemented more simply: if the last context against which a
call was made is not equal to the current context, call the wait()
primitive against this context -- or, depending on how it's
implemented, against the previous context or both contexts. It isn't
really necessary to instrument all of the drawing commands. The
assumption should be that many calls (not just drawing calls) are made
sequentially against any given context.
> But my main concern is that the vast majority of developers will simply not
> realize that by adding that bit of fancy 2D text drawn they are killing
> their performance. The presence of an explicit waitContext() gives them a
> clear warning that switching contexts is expensive.
The incorrect rendering behavior for not calling waitContext() is in
my opinion too big a stumbling block. I think we should advise
developers to stick to one context for best performance, but produce
correct rendering results if they interleave calls to multiple
You are currently subscribe to email@example.com.
To unsubscribe, send an email to firstname.lastname@example.org with
the following command in the body of your email: