http://bugs.freedesktop.org/show_bug.cgi?id=11003
--- Comment #5 from Ian Romanick <[EMAIL PROTECTED]> 2008-12-09 11:25:44 PST --- (In reply to comment #4) > (In reply to comment #3) > > > That patch looks good. That causes the if-statement to be generated for all > > the __glXTexImage#DReqSize functions, right? > > No, it only causes it to generate the if-statement for __glXTexImage3D and 4D. > 1D and 2D don't have a null flag so it wouldn't work. It also generates them > for the glXTexSubImage family of functions because they do have the NULL flag > - > but I'm not really sure what it means to pass pixels as NULL for a sub image > update. Er...the SubImage calls aren't supposed to have a null_image flag. At least, I don't see it listed in the GLX 1.3 protocol encoding document (http://www.opengl.org/documentation/specs/glx/encode1.3.ps). The field where that flag would be is marked as unused. Who knew that thousands of unreviewed lines of code might have bugs? > > > Why isn't the img_null_flag set for glTexImage2D? At the moment it just > > > redundantly uploads empty data if pixels is NULL. I guess it would be a > > > > I believe that this is the way the original code was implemented. When I > > did > > the Python scripts I tried to reproduce the original code as closely as > > possible. Once this is fixed on the server, we should add an optional fix > > for > > the client. In the past we have been able to control the protocol > > generated by > > the client with environment flags. This isn't the first time when both > > client > > and server handled GLX protocol in the same incorrect way. :( > > After talking with Owen Taylor on IRC and in that Clutter bug report I think I > understand this a bit better. When the GLX protocol was originally specified > there was no glTexSubImage and so it wasn't valid to pass pixels == NULL so it > makes sense that there is no null flag. glTexImage3D was specified after (or > around the same time) as glTexSubImage so it does include a null flag. > > I think to add a null flag to 1D/2D we would need a new GLX protocol extension > and the python code would probably have to special case those two functions to > use the new request if it is supported. I believe that analysis is correct. We could either do a GLX extension or suggest it for a future version (1.5 or 2.0) of the core GLX spec. There are quite a few GLX protocol work items with much higher priority, so I'm not sure when / if this would get done. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug. ------------------------------------------------------------------------------ SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. The future of the web can't happen without you. Join us at MIX09 to help pave the way to the Next Web now. Learn more and register at http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/ _______________________________________________ Mesa3d-dev mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
