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.
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.
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.
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.It just is awkward.. also affects GL state and obscures what I am after: memset a texture.
Um... how to go about this. The information leak is the following for a web browser supporting WebGL:
- Create texture
- Attach texture to FBO
- execute glReadPixels
OR
- Create texture, but do not initialize it
- use the texture to draw contents
- 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.
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.
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.
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.
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.
Did you file a bug with your fixes? If not, please file one at https://www.khronos.org/bugzilla/ent...product=OpenGLOriginally Posted by Alfonse Reinheart
Posting Permissions
