On Tue, Sep 24, 2002 at 02:19:24 +0100, Keith Whitwell wrote:
> Michel Dänzer wrote:
> >On Die, 2002-09-24 at 13:11, Keith Whitwell wrote: 
> >
> >>I've been thinking again about pageflipping & realized I can solve the 
> >>remaining few problems if I can tweak the behaviour of the 2d driver 
> >>slightly.
> >>
> >>At the moment, the 2d driver always draws to buffer zero (the old front 
> >>buffer), and then at some point in the future, the dirty parts are 
> >>blitted to buffer one (the old back buffer).
> >>
> >>However, this can be incorrect in a couple of circumstances, particularly 
> >>when the dirty regions (or even the drawing itself) overlaps with the 3d 
> >>window.
> >>
> >>I think all my problems can be solved if I do two things:
> >>    1) always have X draw to the *current* front buffer (buffer zero or 
> >>    buffer one, depending)
> >>    2) subtract the 3d window from the dirty regions before blitting to 
> >>    the current back buffer.
> >>
> >>I can probably figure out 2) without to much effort.
> >>
> >>For 1), I can adjust the accelerated functions fairly easily to get them 
> >>to draw to buffer zero/one as appropriate.
> >>
> >
> >How do you deal with offscreen access?
> 
> They should remain exactly as they are:  I want to change the offset of the 
> front buffer - I would hope that the two are decoupled, maybe that's a 
> mistake on my behalf.
> 
> 
> 
> >>What about software fallbacks?  What value do these use to get a pointer
> >>to the framebuffer, and how can I go about changing it?
> >>
> >
> >It's passed to xxxScreenInit(), and even if there's a single place where
> >it's stored afterwards, I'm not sure relying on that is a good idea. 
> >
> >Doesn't 2) alone work?
> 
> No, because you should be able to render to the same window with both X and 
> GL and see the results onscreen.  If X always renders to buffer zero, 
> sometimes that won't work.

In theory,

this should work, but I've not tested it.

        {
                PixmapPtr pspix;

                pspix = (*pScreen->GetScreenPixmap) (pScreen);

                (*pScreen->ModifyPixmapHeader)(pspix, pScreen->width,
                    pScreen->height, pScreen->rootDepth,
                    BitsPerPixel(pScreen->rootDepth),
                    PixmapBytePad(pScrn->displayWidth, pScreen->rootDepth),
                    NEWFBPOINTER);
        }

Basically fbScreenInit, passes the framebuffer pointer down to 
miScreenInit, which ends up in miCreateScreenResources later where
the screen pixmap is setup. It essentially does the above too, to setup
this up.

Alan.


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Reply via email to