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. Keith ------------------------------------------------------- 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
