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 5 of 10 FirstFirst ... 34567 ... LastLast
Results 41 to 50 of 96

Thread: Official feedback on OpenGL 4.3 thread

  1. #41
    Senior Member OpenGL Pro
    Join Date
    Apr 2010
    Location
    Germany
    Posts
    1,128
    kRogue: BTW, the workaround could be to use glClearBuffer() on a framebuffer attachment - albeit it's not cool but does essentially what you ask for. I can't help but feel that naming a function glClearBuffer{Sub}Data in the presence of glClearBuffer wasn't the wisest decision to make. Again, to the knowing developer it's not a problem but when seeing it the first time you start thinking.
    Last edited by thokra; 08-09-2012 at 07:59 AM. Reason: Fix crazy sentence.

  2. #42
    Senior Member OpenGL Guru
    Join Date
    May 2009
    Posts
    4,948
    Yes, probably not the best nomenclature. But what else could you call it? glMemsetBufferData? glClearBufferObjectData?

    The ARB was kinda screwed by glClearBuffer; it should have been named something like glClearFramebufferImage or glClearFramebufferAttachment. Something that has "Framebuffer" in it.

  3. #43
    Advanced Member Frequent Contributor
    Join Date
    Apr 2009
    Posts
    590
    The attach texture to FBO and do clear buffer is what I do now. It just is awkward.. also affects GL state and obscures what I am after: memset a texture. This clearing of a texture before use is really freaking important with respect to GL accelerated browsers. Oh well. I'll live, for now.

  4. #44
    Senior Member OpenGL Guru
    Join Date
    May 2009
    Posts
    4,948
    It just is awkward.. also affects GL state and obscures what I am after: memset a texture.
    You assume that the hardware implementation would not have to do the same thing: use the framebuffer clearing mechanism to clear the texture's data. Remember: doing an actual clear like this on texture memory is not exactly a common operation. 99 times out of 100, if you're clearing an image, it's because you're about to render to it. Textures not meant to be render targets are typically uploaded to, not cleared.

  5. #45
    Advanced Member Frequent Contributor
    Join Date
    Apr 2009
    Posts
    590
    Um... how to go about this. The information leak is the following for a web browser supporting WebGL:
    1. Create texture
    2. Attach texture to FBO
    3. execute glReadPixels

    OR
    1. Create texture, but do not initialize it
    2. use the texture to draw contents
    3. glReadPixels from the framebuffer


    now if a WebGL implementation does not clear the texture before it is used (as far as the user of WebGL is concerned) then a WebGL process can read image data from discarded memory, in particular previous image data held in texture be it in the same browser process or even a completely different program.

    This is bad. So a WebGL implement must add additional code to either track if the texture was cleared already or all of it set, etc... which is a right pain in the rear when all one wants is the ability to memset the freaking memory when it is allocated.

  6. #46
    Senior Member OpenGL Guru
    Join Date
    May 2009
    Posts
    4,948
    Why exactly is this bad? You may be reading image data from discarded memory. You may not. It's certainly not something reliable, and even if it were, all you get is... a picture.

  7. #47
    Advanced Member Frequent Contributor
    Join Date
    Apr 2009
    Posts
    590
    Ahh.. a picture.. from a secure website...maybe your private chats, maybe online banking... There are already attacks of this form. It is a security risk, it leaks information. The picture can be sent to a remote sight for analysis, etc.... Blackmail, forgery, etc.

    Leaking information, like a freaking screenshot is a security risk.

    At any rate, lets get back on target: I'd like a glClearTexture call rather than bind framebuffer, attach texture, call glClear**(). They had the chance with the "immutable texture" thing introduced, just wish those texture making functions included a memset value. Whine whine, I'd like some cheese please.

  8. #48
    Member Regular Contributor
    Join Date
    Apr 2009
    Posts
    268
    Are you doing implementaion of WebGL or something?
    There certainly is security vulnerability possible to implement, but i dont think its that of a big deal (as in, for the driver - i hope its a big deal for the browsers).

    It would probabaly be best to specify context flag that would require all 'uninitialized' bits to be set to zero, without any API overhead.

  9. #49
    Senior Member OpenGL Guru
    Join Date
    May 2009
    Posts
    4,948
    Sorry, I seem to have missed an award:

    We Can't Be Bothered To Use A Diff File To Fix Our Spec Bugs

    This one goes to whomever is responsible for maintaining the .spec files.

    Some time ago, I made a .diff file available that fixes a large number of .spec bugs. Missing enumerators, wrong enumerators, etc. And yet... those .spec bugs still exist.

    It's really not that hard to run `patch` over the .spec files, guys. I did the hard work for you.

  10. #50
    Junior Member Newbie
    Join Date
    Aug 2009
    Location
    Ottawa, Canada
    Posts
    5
    Quote Originally Posted by Alfonse Reinheart View Post
    Some time ago, I made a .diff file available that fixes a large number of .spec bugs. Missing enumerators, wrong enumerators, etc. And yet... those .spec bugs still exist.
    Did you file a bug with your fixes? If not, please file one at https://www.khronos.org/bugzilla/ent...product=OpenGL

Posting Permissions

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