[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Public WebGL] getContext multiple context language
Kenneth Russell wrote:
I repeat my previous objections.
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.
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 everything.
You previously wrote:
In earlier discussions it was stated that if the developer fails toThe results will be incorrect on all implementations. Are you saying you
want to have identical incorrect results across implementations?
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 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.
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.
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.
org:HI Corporation;Graphics Lab, Research & Development
adr:Higashiyama 1-4-4, Meguro-ku;;Meguro Higashiyama Bldg 5F;Tokyo;;153-0043;Japan
tel;work:+81 3 3710 9367 x228
tel;fax:+81 3 5773 8660