Part of the Khronos Group
OpenGL.org

The Industry's Foundation for High Performance Graphics

from games to virtual reality, mobile phones to supercomputers

Page 1 of 2 12 LastLast
Results 1 to 10 of 17

Thread: New XML-based API Registry released

Hybrid View

  1. #1
    Administrator Contributor
    Join Date
    Jan 2002
    Location
    Mt. View, CA
    Posts
    97

    New XML-based API Registry released

    The old gl.spec & related files are being retired, replaced by an XML-based description of the GL, GLX, WGL, GL ES, and EGL APIs as has been promised since slightly before the Dark Ages. The XML files & Python scripts to process them and generate headers are in the public-access portion of Khronos Subversion, and the GL, GLX, and WGL headers generated from them are also there and linked from the registry index.

    The GL, GLX, and WGL headers should be equivalent to the old headers generated from .spec, although they are structured differently and in some cases, enums and entry points have moved from one extension #if block to another (each extension / core version now references all the tokens and commands it introduces, even if some prior extension also references them, and if a token or entry point appears in more than one extension, it will only appear in the .h at the first place it's referred to). The GLES and EGL headers on the Khronos Registry website will probably be updated to be generated from the corresponding Registries fairly soon, if the corresponding Working Groups are OK with that.

    The new format includes a Relax NG compact schema, and all the XML validates against that. There's a short description of the tags in the README.txt. It captures most, but not all of the information in the .spec files in a more semantically expressive way, describes types in C syntax instead of the generic type syntax used in .spec, and does not include array length information (which was often inaccurate in the .spec files). If you are using .spec to generate bindings to other languages, you'll have to translate the C types to your output types. The header generation scripts are intended to be extensible to other output formats fairly easily, though we haven't done anything with it but C headers.

    The old .spec files and GL, GLX, and WGL headers generated from them are still available under a relocated Subversion path, but we don't plan to update .spec in the future. A large number of .spec bugs that people had submitted have been addressed in the XML registry and closed, or in a few cases, WONTFIXed because they referred to specific properties of .spec that don't exist in the XML. It might be possible to do a mechanical translation from the XML back to .spec format - it would not be easy, because the XML is structured very differently and there are a lot of one-off hacks in .spec that aren't needed in the XML - but hopefully people can adapt their uses to work directly with the XML instead. It's possible the schema will need additions to accomodate some uses, feedback on that can be provided here.
    Jon Leech
    Khronos API Registrar
    ARB Ecosystem TSG Chair
    GL/EGL/GLES Spec Editor
    ...and suchlike

  2. #2
    Senior Member OpenGL Guru
    Join Date
    May 2009
    Posts
    4,948
    Thank you for doing this.

    Also, you now have your first bug report on the new spec files Followed by two more

  3. #3
    Senior Member OpenGL Pro
    Join Date
    Apr 2010
    Location
    Germany
    Posts
    1,099
    Relax NG compact schema
    Most awesome!

  4. #4
    Senior Member OpenGL Guru
    Join Date
    May 2009
    Posts
    4,948
    Quote Originally Posted by thokra View Post
    Most awesome!
    Even better, it has actual documentation in it explaining what the elements mean.

  5. #5
    Senior Member OpenGL Pro
    Join Date
    Apr 2010
    Location
    Germany
    Posts
    1,099
    Quote Originally Posted by Alfonse
    it has actual documentation
    *rubs eyes for about a minute*

    Well damn, this is almost like solid software engineering.

  6. #6
    Administrator Contributor
    Join Date
    Jan 2002
    Location
    Mt. View, CA
    Posts
    97
    The "actual documentation" is more complete (and prettier) now: see PDF
    Jon Leech
    Khronos API Registrar
    ARB Ecosystem TSG Chair
    GL/EGL/GLES Spec Editor
    ...and suchlike

  7. #7
    Junior Member Regular Contributor Lucretia's Avatar
    Join Date
    Mar 2000
    Location
    Leeds, West Yorkshire, England
    Posts
    117
    Hi,

    Well, it's about time this happened tbh, but from my cursory look I am surprised that:

    1. You've kept the C stuff inside the main XML files where they really should be external to that and kept somewhere language specific.
    2. You've added "GL_" and "gl" where the original specs didn't, this means all strongly typed languages have to go through the aggro of checking for and stripping them.
    3. You seem to assume all enums are bitfields to be ANDed together where in the original specs you could easily see they were separate, had specific values and were not all enumerations, i.e. some are constants of a type to be ANDed.


    I could be wrong, I hope I am, but this is what I saw.

    Thanks,
    Luke.
    Luke A. Guest

  8. #8
    Administrator Contributor
    Join Date
    Jan 2002
    Location
    Mt. View, CA
    Posts
    97
    You seem to assume all enums are bitfields to be ANDed together where in the original specs you could easily see they were separate, had specific values and were not all enumerations, i.e. some are constants of a type to be ANDed.
    I'm not sure what you mean by this. Enums that are bitmask values are tagged as such, e.g.

    <enums namespace="GL" group="AttribMask" type="bitmask">
    <enum value="0x00000001" name="GL_CURRENT_BIT"/>
    ...

    You're correct on the other two points. OpenGL is explicitly defined as a C API and the XML registry reflects that now, while the .spec files pretended that wasn't the case - which resulted in a lot of pain for me, slow updates, and a fair number of errors creeping in over the years resulting from the typemap system. There is some discussion upthread about ways to help accomodate the differences if you want to mechanically translate the API to other language bindings, but it is true that you'll have to do some things differently than with the .spec files, and do some additional type translation work. Hopefully the benefits of a well-defined XML schema, more accurate description of the relationship between features and GL versions/profiles, ES support, and much more frequent updates will balance that out for most people.
    Jon Leech
    Khronos API Registrar
    ARB Ecosystem TSG Chair
    GL/EGL/GLES Spec Editor
    ...and suchlike

  9. #9
    Newbie Newbie
    Join Date
    Aug 2013
    Posts
    2
    Would you be able to use a typemap like the old specs did?



    This would make it far easier for folks that are trying to generate loaders for other languages that don't follow the C declaration syntax.

    Anyway, thanks so much for your work, you have made our lives much easier.

  10. #10
    Newbie Newbie
    Join Date
    Aug 2013
    Posts
    1
    As the (currently sole) maintainer of the Delphi (and Free Pascal) OpenGL headers over at delphigl.com I must admit that I'm pretty happy with the release of the XML-based API files. It only took me two weekends to write a converter that automatically creates a complete Delphi / Free Pascal OpenGL header with the click of one single button, and just half an hour ago I even got an OpenGL 4.x template working with that generated header

    So from now one I don't have to do a diff with the C-headers to check what's changed and merge that manually into our headers anymore. Instead I now just download the latest XML definition, click a button and it's done. The only thing I'm currently struggling a bit with are type mappings, cause there are some differences between data types and their declarations between Delphi (Free Pascal) and C, and I also want the new header to be compatible to our old ones.

    But I'd say the new XML definitions are a step in the right direction, especially for generating headers / wrappers for other languages.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •