[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Public WebGL] getContext multiple context language
On Sun, Feb 7, 2010 at 7:35 PM, Mark Callow <email@example.com> wrote:
> Kenneth Russell wrote:
> On Fri, Feb 5, 2010 at 12:17 AM, Mark Callow <firstname.lastname@example.org>
> 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.
> How exactly does the implementation know which is the "current" context?
> Aren't all the functions method calls on a context object? In which case the
> application can interleave calls without the implementation being any the
> wiser, unless it instruments the calls.
The implementation already tracks which context was last used to make
a drawing call. This is required in order to support rendering into
multiple canvases via WebGL.
> 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
> I do not understand why incorrect rendering for a buggy program is such a
> stumbling block. Why is failure to put in a required waitContext call any
> different than any other omission that prevents the program producing
> correct results?
The waitContext calls would only end up being something the developer
would forget. Because the implementation must already do all of the
checking to determine whether an implicit waitContext() is necessary,
it should do them automatically. The failure mode is also undesirable;
the developer will probably get correct rendering on some platforms
and then deploy their app, which will silently produce corrupt
rendering on other platforms. With the implicit waitContext their app
will at least work, and then it is up to them to tune its performance.
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: