On Die, 2002-09-24 at 18:37, Alan Hourihane wrote:
> On Tue, Sep 24, 2002 at 05:06:13 +0100, Keith Whitwell wrote:
> > Alan Hourihane wrote:
> > >Keith,
> > >
> > >This should do it.
> > >
> > > {
> > > PixmapPtr pspix;
> > > pspix = (*pScreen->GetScreenPixmap) (pScreen);
> > > (*pScreen->ModifyPixmapHeader)(pspix, 0, 0, 0, 0, 0,
> > > info->FB + XXXXXXXOFFSETXXXXX );
> > > }
> > >
> > >Alan.
> >
> > Alan, do you have a feel for how this will affect XAA and offscreen
> > pixmaps, pixmap caches, etc?
> >
> > My guess is that it will break them, but I live in hope...
>
> It might not break them, the pixmap cache gets cracked down via
> the PutImage (or PutImage/CopyArea) path which gets passed
> through to our ImageWrite/ScreenToScreen accelerator code.....
But that's exactly the problem - XAA doesn't know about the different
buffers so the coordinates will be wrong when we render to the 'back'
buffer (the pixmap cache is always at a fixed location in the
framebuffer).
> Um, might have to remove that GXCOPY_ONLY flag on ImageWrites though.
You mean NO_GXCOPY? That's only used in the MMIO code.
> But, the alternative path is...
>
> If we code up 'WriteBitmap' and 'WritePixmap' which deals with
> pixmap cache loading and hook these into our _accel.c functions,
> then we should be able to remove the pixmap cache flag called
> LINEAR_FRAMEBUFFER. This is a more direct path and might be
> slightly faster. That should do the trick if the above doesn't.
That sounds interesting.
But what about the source coordinates when XAA renders from the cache to
the screen?
--
Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer
XFree86 and DRI project member / CS student, Free Software enthusiast
-------------------------------------------------------
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
