Re: [Mesa3d-dev] update on GL_EXT_framebuffer_object work

[Nicolai Haehnle]

On Tuesday 17 May 2005 15:47, Brian Paul wrote:
> > 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.
> 
> That actually sounds like the right thing.
> 
> The idea is that when the driver learns that the window has been 
> resized we need to call _mesa_resize_framebuffer() on the framebuffer 
> that corresponds to the window.  Wherever we recompute the cliprects 
> in response to a window size change, is also the right place to resize 
> the Mesa framebuffer.
> 
> This should be addressed in all the DRI drivers.
> 
> If you can provide the details of how/where you're doing this in the 
> r300 driver, we can look at doing the same in the other drivers.

In the r300 driver, the function radeonGetLock() is the function that 
handles all the non-fast cases of LOCK_HARDWARE. In this function, we call 
r300RegainedLock() after validating the drawable information.

I have changed r300RegainedLock() to look like this:

static void r300RegainedLock(radeonContextPtr radeon)
{
        __DRIdrawablePrivate *dPriv = radeon->dri.drawable;

        if (radeon->lastStamp != dPriv->lastStamp) {
                /* --- Here is the interesting part --- */
                _mesa_resize_framebuffer(radeon->glCtx,
                        (GLframebuffer*)dPriv->driverPrivate,
                        dPriv->w, dPriv->h);

                ... recalculate cliprects and scissor stuff here ...
        }
}

Inserting this call to _mesa_resize_framebuffer was the only relevant 
change.

cu,
Nicolai

pgpntrjtOrF66.pgp
Description: PGP signature