[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Public WebGL] "context creation parameters"
- To: Glenn Maynard <firstname.lastname@example.org>
- Subject: Re: [Public WebGL] "context creation parameters"
- From: Kenneth Russell <email@example.com>
- Date: Wed, 4 Apr 2012 18:36:26 -0700
- Cc: public webgl <firstname.lastname@example.org>
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding:x-system-of-record; bh=iR2qRw90EGEGdAChXEUYh7qhMuKARaVTPosSYWSu4n4=; b=e1Pq2+Wm9mZjWzSnlcsYFJV9jJNpNRQYXP6Np2WsoDHGtCYEAuyiOa/9s2DzIFm+eO bsGRB7gn3n4ea20+/m3zN4MnbUXOAJ4EV1viSRAcXUHBIsTnduALiePw7OScIv62CMSE lCXIEDq4vrVYNBKluApeOS1jXw+GKUWxUBcHZyhom2FhHLlaVN71Q7M3wG72q9rDwmUw /ICbIitm0ct1fz0KapaDRAfBnFFxuxUmOVC1kbR/eswH0/1RlsQj7dCbjGh5nW54ugEp 4vfMZFlaiQKvDgv2DxRBwHOk3qZ03MyscXi0FDHtnOUiZacYNgF6weK0QBKLJmvnmi27 elMw==
- In-reply-to: <CABirCh-1MnhT5vxYZQ-R2BAPUTtfo2T89CGBzvw1pTmm9UFvZA@mail.gmail.com>
- List-id: Public WebGL Mailing List <public_webgl.khronos.org>
- References: <CABirCh-1MnhT5vxYZQ-R2BAPUTtfo2T89CGBzvw1pTmm9UFvZA@mail.gmail.com>
- Sender: email@example.com
On Wed, Apr 4, 2012 at 5:51 PM, Glenn Maynard <firstname.lastname@example.org> wrote:
> I recall that it was meant to be possible for a context to be lost, then on
> context restoration, to end up with different parameters. (For example, if
> the browser window is moved to a different window that's running on a
> different graphics card, or if the capabilities change when a tablet is
> docked.) I think we ended up with a bug related to this in context
> The "context creation parameters" are used to restore the context (5.15.3
> step 3), but the context creation parameters are also *set* to the results
> of "create a drawing buffer"; that's what "The attributes actually used to
> create the context..." implies. This means that, each time the context is
> lost and restored, the new drawing buffer is created with parameters based
> on the previous creation. You end up with f = func(f); f = func(f); f =
> func(f); in other words, the creation parameters can constantly drift, as
> each new set of parameters changes the result.
> I think what's actually intended is to create a drawing buffer using the
> *original* WebGLContextAttributes, so we always try to get as close to the
> original request as possible, not to the previous result.
> To fix this, I'd recommend:
> 1: In 2.1, below "context creation parameters", add a similar definition:
> "Each WebGLRenderingContext has actual context parameters, set each time the
> drawing buffer is created, which is a WebGLContextAttributes object." (The
> initial value doesn't matter; it should be impossible to access this
> definition before the drawing buffer is created.)
> 2: In 2.2 "The Drawing Buffer", replace "The attributes actually used..."
> with: "The actual context parameters are set to the attributes of the
> created drawing buffer." (Mentioning getContextAttributes here becomes
> redundant, so should be removed, but it could be mentioned in the note
> 3: In 5.14.2 getContextAttributes, replace "context creation parameters"
> with "actual context parameters".
> This also fixes a minor error: it says "used to create the context", when it
> should have said "used to create the drawing buffer". It also makes setting
> the results of drawing buffer creation clear; "The attributes actually used
> ..." was a little ambiguous (it could be interpreted to mean "the original
> parameters to getContext" instead of the resulting configuration).
Thanks for pointing this out. I've made the changes you suggest, which
also resolves your concern on the other thread about the changes to
> There might also be value in giving a way to access the context creation
> parameters, eg. a copy of the original parameters passed to getContext; for
> example, "getOriginalContextAttributes". It's not critical, since you can
> always store it yourself, but possibly useful.
I don't think there's a strong need to expose the originally requested
> (As I mentioned previously, I'm still trying to think of a phrasing of "...
> parameters" that avoids being plural, since both of these are really a
> single object.)
If you have further thoughts on this please email the list.
> Glenn Maynard
You are currently subscribed to email@example.com.
To unsubscribe, send an email to firstname.lastname@example.org with
the following command in the body of your email: