From: Ian R. <id...@us...> - 2003-04-29 15:31:14
|
Philip Brown wrote: > On Tue, Apr 29, 2003 at 03:18:35AM +0100, Matt Sealey wrote: > >>>Yeah, hooks for that stuff in GLframebuffer would be a good thing too, IMO. >> >>A good thing? Think about it. There is no real specified limit to the number >>of GL_AUXi buffers. > > > Eh. There are various ways to deal with that. But, AUX buffers are > *optional*. Color buffers are _mandatory_ to OpenGL, in some form or other. > So, I dont see it as that big of a deal whether GLframebuffer has > AUX hooks or not. But I think it makes sense to have hooks for the > specification-mandatory stuff. Conceptually, we have a base class called GLframebuffer. Each specific driver derives from that base class. It just happens that all of the derived classes have pointers to some pixel data, perhaps some stencil data, perhaps some depth data, and perhaps some AUX data. In some cases it's a pointer to a basic type (GLubyte, GLuint, etc.), but, as Matt pointed out in another message, that may not always be the case. Is that a fair assessment of the code as it stands? What's being discussed here is pulling at least some of those data members out of the derived classes into the base class. Since the derived classes don't all use the same data all of the data would be "void *". Is that a fair assessment of what is being disucussed? The problem I have with all of this is that we're losing information in the code. We're going from "GLubyte *" to "void *". That is a loss of information. In general, I think that's a bad thing. We have two seemingly conflicting goals. One goal is to refactor and simplify the code. The other goal is to maintain the information content of the source code. The fact that the presented sollution has generated such heated, entrenched "debate" should put up a warning flag that it might not be the best over-all sollution. We're all clever people here. Aren't we selling ourselves short if we can't try to find another option? Afterall, isn't finding the other option what open-source is all about? :) Instead of having extra data members for each buffer element in GLframebuffer, why not have a single pointer to a collection of elements? For example: struct GLbufferDataRec; /* Defined in the driver. Not used directly by * Mesa. */ struct GLframebufferRec { ... struct GLbufferDataRec * buffers; }; Then each driver could define its own GLbufferDataRec structure with whatever data, with whatever types it needs. Since Mesa never touches any of the data stored in the memory at *buffers, it would not need to know anything about GLbufferDataRec. This would pull the data into the base class, but still let the derived classes define the format of the data. Mesa could even provide a sample implementation. To be perfectly honest, the fact that the data is never used by the base class makes me wonder if it belongs there at all. |