Alan Hourihane wrote:
> 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.
It would be good to get Page Swapping working in the server. Not only
is this very valuable for 3D performance, but the X double buffer
extension should utilize this as well.
Perhaps we'll need to move this discussion to the xpert list, but first,
I'll ask here. Does anybody know of any applications that use DBE? If
not, we should remove it. If so, we need to fix it when the DRI is
enabled. The GLX spec clearly states:
"All GLX rendering contexts share the same notion of which are front
buffers and which are back buffers for a given drawable. This notion is
also shared with the X double buffer extension (DBE)."
Currently, DBE buffers are managed as X Pixmaps and DRI drivers have not
notion of DBE buffers. Any application that used OpenGL and DBE
together would be broken, but I haven't seen any bug reports along this
line. I have to conclude that no applications are using OpenGL and DBE
together.
Note: DBE and DRI cooperation has been broken for a long time. Keith's
work on page flipping is *not* the start of the problem, but it does
present an opportunity for us to fix DBE, or dump it.
--
/\
Jens Owen / \/\ _
[EMAIL PROTECTED] / \ \ \ Steamboat Springs, Colorado
-------------------------------------------------------
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
