On Tue, Sep 24, 2002 at 02:49:37 +0100, Alan Hourihane wrote:
> 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.
In fact, scratch that, looking furthur shows that the miCreateScreenResources
stores the Pixmap pointer in the devPrivate.
I'll do some digging.
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
