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 4 123 ... LastLast
Results 1 to 10 of 31

Thread: GL_EXT_abgr

  1. #1
    Intern Contributor
    Join Date
    Oct 2002
    Posts
    78

    GL_EXT_abgr

    GL_EXT_abgr is the oldest EXT and universally supported as far as I can tell. But somehow has never made it into the core or even to an ARB extension.

  2. #2
    Senior Member OpenGL Lord
    Join Date
    May 2009
    Posts
    6,003

    Re: GL_EXT_abgr

    Well, think about it: what good is it exactly?

    The pixel transfer parameters GL_ABGR_EXT and GL_UNSIGNED_INT_8_8_8_8 are the exact same as GL_RGBA with GL_UNSIGNED_INT_8_8_8_8_REV. The same goes for 4444 and 4444_REV. The only place where there would be a difference is 5551 vs. 1555_REV.

    Do you need to do ABGR uploading for 16-bit per-channel formats? I doubt the hardware orders the channels that way, so I don't think it's going to help anything.

    Just because something is an extension and widely supported doesn't mean that it's good or needs to be brought into core.

  3. #3
    Advanced Member Frequent Contributor
    Join Date
    Apr 2009
    Posts
    612

    Re: GL_EXT_abgr

    Just because something is an extension and widely supported doesn't mean that it's good or needs to be brought into core.
    Funny that, one would think that it is evidence that it is used and supported which implies a candidate to go to core.

  4. #4
    Intern Contributor
    Join Date
    Oct 2002
    Posts
    78

    Re: GL_EXT_abgr

    GL_UNSIGNED_INT_8_8_8_8_REV is not a solution if writing cross-platform code because of endianess issues.

  5. #5
    Senior Member OpenGL Lord
    Join Date
    May 2009
    Posts
    6,003

    Re: GL_EXT_abgr

    Funny that, one would think that it is evidence that it is used and supported which implies a candidate to go to core.
    What is the evidence that it is widely used? Supported, yes. Used?

    GL_UNSIGNED_INT_8_8_8_8_REV is not a solution if writing cross-platform code because of endianess issues.
    And ABGR is? How are these two any different with regard to endian issues?

    If you're having endian issues, you should be using GL_PACK/UNPACK_SWAP_BYTES anyway.

  6. #6
    Intern Contributor
    Join Date
    Oct 2002
    Posts
    78

    Re: GL_EXT_abgr

    Quote Originally Posted by Alfonse Reinheart
    And ABGR is? How are these two any different with regard to endian issues?
    Because the order of bytes is preserved across different endian platforms but the order of unsigned ints is not. Thus GL_ABGR_EXT w/ GL_BYTE will give you the same results across platforms which GL_UNSIGNED_INT_8_8_8_8 will not.

    Quote Originally Posted by Alfonse Reinheart
    If you're having endian issues, you should be using GL_PACK/UNPACK_SWAP_BYTES anyway.
    This suffers from the exact same endian problem as using unsigned ints. It introduces a separate code path across platforms and also obfuscates the meaning of the code.

  7. #7
    Senior Member OpenGL Lord
    Join Date
    May 2009
    Posts
    6,003

    Re: GL_EXT_abgr

    This suffers from the exact same endian problem as using unsigned ints. It introduces a separate code path across platforms and also obfuscates the meaning of the code.
    Except that you only have to set it in one place at the beginning of your code. And from then on, everything works. That's the problem with ABGR; you can already get the equivalent functionality without it.

    Also, I would point out that the swap-bytes solution will also work for 16-bit shorts, 16-bit floats, 32-bit shorts, 32-bit floats, 16-bit 565, 16-bit 4444, 32-bit 10F_11F_11F, 32-bit 5999, ... I can keep going, but I think my point is clear. ABGR solves this for exactly one format (ie: bytes). Swap bytes solves it for everything.

    Hence swap bytes is standard, and ABGR is not.

  8. #8
    Intern Contributor
    Join Date
    Oct 2002
    Posts
    78

    Re: GL_EXT_abgr

    I'm not going to argue with you Korval.

  9. #9
    Advanced Member Frequent Contributor
    Join Date
    Dec 2007
    Location
    Hungary
    Posts
    989

    Re: GL_EXT_abgr

    I agree with Alfonse on this, endianness issues are what the GL_PACK/UNPACK_SWAP_BYTES pixel transfer option is made for. Adding GL_EXT_abgr to core would result simply in redundant functionality.
    Disclaimer: This is my personal profile. Whatever I write here is my personal opinion and none of my statements or speculations are anyhow related to my employer and as such should not be treated as accurate or valid and in no case should those be considered to represent the opinions of my employer.
    Technical Blog: http://www.rastergrid.com/blog/

  10. #10
    Senior Member OpenGL Pro
    Join Date
    Jan 2007
    Posts
    1,789

    Re: GL_EXT_abgr

    The other option is to detect your endianness at startup and use formats and types as appropriate. That will also work, and will also be portable.

    To be honest portability seems a fairly weak excuse for saying "thou shalt not" when there are plenty of options available to deal with it.

Posting Permissions

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