Keith Whitwell wrote: > Brian Paul wrote: > >>Ian Romanick wrote: >> >>>-----BEGIN PGP SIGNED MESSAGE----- >>>Hash: SHA1 >>> >>>It looks like adding support for GLX_SGI_make_current_read is almost as >>>easy as just enabling the extension thanks to Mesa's internal >>>framebuffer object changes. Thanks Brian! >>> >>>However, there is one thing that I don't get. Each driver supplies a >>>GetBufferSize callback. This callback is passed a GLframebuffer >>>pointer, but all of the drivers ignore it. They simply return the size >>>of the currently bound drawable. Should these functions determine if >>>the supplied GLframebuffer is the current drawable or readable and >>>return the appropriate size? >> >>GetBufferSize() should return the width/height of the X window (or >>Pbuffer) that corresponds to the given GLframebuffer. >> >>Unfortunately, GetBufferSize() isn't correctly implemented in most >>(any?) DRI drivers. It really needs to be fixed to support >>make_current_read. > > > Well, actually it is impossible to implement correctly. For any given > window you have a possible implementation: > > LOCK_HARDWARE() > (do something to update window dimensions) > UNLOCK_HARDWARE() > > The trouble is that as soon as you unlock the hardware, the window > dimensions are no longer trustworthy. If you use those values in such a > way that carries over to another hardware interaction, you end up with > potentially incorrect rendering. > > This has lead to real bugs in things like the driver clear functions - > Mesa attempts to pass in some x,y,w,h values to the clear function under > certain circumstances (when the 'all' parameter is non-true). These > values are not trustworthy and must be recalculated once LOCK_HARDWARE > has been called again. > > In general, GetBufferSize is not an answerable question. It's been a > vague irritant for a long time, but up until bugs like the above started > surfacing I was sort of ok about ignoring the issue. I need to get a > better understanding of where the buffer size values are used and under > what conditions they need to be updated. As it stands I think there are > any number of latent bugs hidden behind the assumption that we can know > what size a window is when the hardware lock is not held.
Actually, GetBufferSize() isn't used much anymore. I was trying to move away from it when I did the FBO work. Currently, it's only used into two places: 1. In _mesa_make_current() - we need to initialize the context's viewport and scissor box size to the drawbuffer's size. If we can be sure the GLframebuffer's Width/Height are set properly by the driver before _mesa_make_current() is called, we could remove GetBufferSize() there. 2. In _mesa_resizebuffers(newCtx) - this is called from the (mostly obsolete) _mesa_ResizeBuffersMESA() API function. However, I see that you added a new call to this function in _mesa_make_current() on September 22. Do you remember why? In the case of (1), the buffer's width/height doesn't have to be 100% correct. If someone is actively resizing a window at the moment that the context is being bound for the first time, the buffer's going to get resized again later and the app will likely update the viewport/scissor if needed anyway. My intention, since the FBO work, is for the driver to call _mesa_resize_framebuffer() when it has the lock and has detected a change in window size. I believe I updated all the DRI drivers to do just that. Finally, there's the ctx->Driver.ResizeBuffer() function. This is on the verge of going away too. It's only used in (1) and (2) and can likely go away once the point in (1) is addressed. -Brian ------------------------------------------------------------------------- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 _______________________________________________ Mesa3d-dev mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
