Re: GLX in bad state
Ove Kaaven <[email protected]>
| Newsgroups | gmane.comp.emulators.winex.devel |
|---|---|
| Organization | TransGaming Technologies Inc |
| Message-ID | <1081177597.16691.1533.camel@renegade> |
man, 05.04.2004 kl. 15.06 skrev Nadav Frum: > Here is an excerpt from the ARB_render_texture Spec Overview: > > This extension may provide a performance boost and reduce memory > requirements on architectures that support rendering to the same > memory where textures reside and in the same memory format and layout > required by texturing. The functionality is similar to CopyTexImage1D > and CopyTexImage2D. However, some changes were made to make it easier > to avoid copying data: > > (Interpretation: Same memory format and layout.) And when that's not the case, the extension may not provide the performance boost, but it may still reduce memory requirements, which can still be useful. And OpenGL has always been an API where functionality and device independence is more important than performance, so I wouldn't be surprised if this extension was designed to function everywhere, even on hardware where there would be no gain whatsoever, just so it would be possible to make it a standard OpenGL feature in the future. > >From the Implementation Notes: > > 1. In order to prevent releases of a pbuffer from the texture object > and to deal with implicit release followed by an explicit release, > the GL implementation can keep a reference to any texture pbuffer > in the texture object. When the pbuffer is released, this handle > is set to NULL. Subsequent requests for releasing the texture > pbuffer are ignored. > > You create a texture by temporarily binding a pbuffer. The texture > image does not persist after you release the pbuffer. But the depth/stencil buffer does, which is what I said, and which you have still said nothing whatsoever to disprove. So please get with the program and stop shooting at strawmen.