Re: [Glsdk-devel] GLE interface discussion.

[Branan R. <br...@gm...>]

Shouldn't the extension string returned by the GL only include the
extensions for the context version anyway? Is there really a need to set the
version twice? (Once for context and once for extensions)

GLX supports extensions natively. You don't need a context to see what
extensions are available, or to get the GLX entrypoints, IIRC.

On Sat, Sep 13, 2008 at 1:08 PM, Jason McKesson <ko...@gm...> wrote:

> OK, so I've finished with the parsing work. I can gather up a list of
> enums and extension entrypoints for GL, WGL, and GLX. I even have some
> preliminary code generation scripts.
>
> But, as I started actually generating code, I came to realize that there
> are larger questions that we should probably discuss before I take an
> action.
>
> Here is my plan for how GLE will work from a user perspective.
>
> The API will provide this interface function:
>
> gleLoadFunctions(GLint majorVersion, GLint minorVersion);
>
> This will load all functions and extensions up to the given GL version.
> It will work similarly to the way ARB_create_context is specified to do.
> That is, if the version given is 2.1 or less, it will load whatever
> extensions and functions it can up to version 2.1. This includes the
> core extensions released with 3.0. If the version is 3.0 or greater, it
> will load exactly and only that version and whatever extensions apply to
> it. Giving it the wrong version for the current GL context (2.1 context
> but 3.0 loading) then this function will return an error.
>
> We will provide headers that expose enums and entrypoints, but they will
> be versioned. There will be a 2.1 header that exposes 2.1 appropriate
> functions and enums, and there will be a 3.0 version. When 3.1 comes
> out, there will be a version for that too which is separate from the
> others.
>
> If the ARB decides to release a new version that is backwards compatible
> with the old one, (if they decide not to remove the deprecated features
> in 3.0 for the 3.1 release) then we will still have separate headers,
> but one can simply #include the other.
>
> This all does not mean that headers from one version cannot be used with
> another version. For example, if 3.1 does remove the deprecated
> features, you can still use the 3.0 headers; what matters is what
> context you create and what version you pass to gleLoadFunctions.
>
> BTW, I call it "load functions" rather than "load extensions" for
> marketing reasons. Since you have to use this just to use any modern GL
> version, it sounds silly to a GL newbie to call these things "extensions."
>
> Speaking of context creation, I don't know how it works in GLX, but WGL
> creates a certain stress on the creation of contexts. Often, when making
> a GL context, you want to create a fake context just so that you can get
> access to wglGetExtensionsStringARB and load the WGL extensions.
>
> Because of that, it is useful to have the following function:
>
> gleLoadWinFunctions();
>
> This loads only the WGL/GLX extensions. It requires a valid GL context,
> but you can destroy that context afterwards and the WGL/GLX functions
> should still be available.
>
> The API will also provide global variables, one per extension, which
> will be 0 if the extension is not available and 1 if it is. These
> variables will only be viable if one of the two load function calls has
> been made.
>
> The structure of the headers will look like this:
>
> gle_2_1.h
> gle_3_0.h
> gle_wgl.h
> gle_glx.h
> gle_main.h
>
> The first two headers are for the core GL enums and functions. The next
> two are for WGL/GLX enums and functions. gle_main.h is where
> gleLoadFunctions and gleLoadWinFunctions is defined. Any header that
> contains enums and functions will also define the global variables that
> one uses to tell whether the extension is available, but only for those
> extensions that it has.
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's
> challenge
> Build the coolest Linux based applications with Moblin SDK & win great
> prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
>