On Monday 02 May 2005 16:56, Brian Paul wrote: > > This weekend I finished updating the DRI drivers to work with the new > framebuffer/renderbuffer changes. My DRI test system is terribly out > of date so I haven't run any tests. I'm tempted to just check in the > changes now and help people fix any problems that arise, rather than > spend a few days updating my test box. I think the code changes are > pretty safe though. > > Here's a summary of changes to the DRI drivers: [snip] > Are there any questions or concerns?
Working on the experimental R300 driver, I did come upon a question: How are DRI drivers supposed to handle window resizes? If I understand the code correctly, _mesa_resize_framebuffer would have to be called at some point when the window is resized, but I don't see when that happens in any of the DRI drivers in Mesa CVS. Note that it can be easy to be miss this problem. One way that should trigger the issue in all drivers is: 1. Make sure that you hit software rasterization fallbacks (e.g. no_rast=true). 2. Run any GL application in a window and resize the window. If you make the window larger than its initial size, the framebuffer will be clipped incorrectly. I've fixed this by calling _mesa_resize_framebuffer in the same place where clip rectangles are recalculated after the DRI lock has been regained. However, I'd like to know if this is the correct/canonical/preferred way of doing it. cu, Nicolai
pgpjIe57zRehm.pgp
Description: PGP signature
