[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Public WebGL] WebGLExtension interface proposal
On Sat, Jun 12, 2010 at 23:29, Chris Marrin <firstname.lastname@example.org> wrote:
>> On Sat, Jun 12, 2010 at 04:49, Chris Marrin <email@example.com> wrote:
>>> I think we may have discussed this and rejected it as not being necessary. I may even have been an advocate of this approach but was convinced that such arbitrary base classes are unnecessary. But I may be confusing this issue with another similar one.
>> really simplify stronger-typed bindings where 'object' are to be
>> avoided whenever possible.
> Right, but a given language binding is free to add any sort of more strongly typed objects as needed. I think the reason for the existance of 'object' is to avoid the need of locking the API into a particular hierarchy unnecessarily.
That's a good point, indeed it adds "unnecessary hierarchy" and
language bindings are free to add more strongly typed objects as
But I see this rather as an advantage, this base class makes sure all
language bindings can use the same base class name (whatever their
implementation is) so it helps WebGL code portability between
Also this could prove necessary/useful if we need to add one method to
all extensions that we might not have envisioned yet... granted this
might fall in the "too much flexibility" trap, however since this is
an extension system we are talking about increased flexibility is not
a disadvantage in this specific case imho.
>> With that addition in mind I assume the concepts are very related :
>> boxed WebGL objects that are acquired and valid only within the same
>> context and within the same lifetime (before context loss), extension
>> objects fit that model.
> I don't think the concepts are that related. The WebGL objects represent actual GL resources. The extension objects just represent a wrapper around a capability. You restore WebGL objects because the GL objects they represent need to be reconstructed. The extension objects need to be restored because you may have a different set of extensions available. These are different concepts.
Slightly different but very similar concepts imo, extension objects
need not to be restored only because you may have a different set of
extensions available, even when the same set of extensions are
available the underlying function pointers might need to be updated
for use within the new context (or driver even). Extensions objects
are rather a collection of function pointers, which are also GL
resources that might have a direct relationship with the context they
have been requested from (through eglGetProcAddress, wglGetProcAddres,
You could say as well that you restore WebGL extensions because the GL
objects (ie. *GL function pointers) they represent need to be
reconstructed (ie. updated/reloaded through *getProcAddress from the
newly constructed GL context).
You are currently subscribed to firstname.lastname@example.org.
To unsubscribe, send an email to email@example.com with
the following command in the body of your email: