[patch] drawing window borders always falls back to software
Michael
macallan at netbsd.org
Thu Sep 24 14:55:59 PDT 2009
Hello,
On Thu, Sep 24, 2009 at 5:25 PM, Aaron Plattner <aplattner at nvidia.com>wrote:
> On Thu, Sep 24, 2009 at 02:10:55PM -0700, Michael wrote:
> > Hello,
> >
> > I finally found out why drawing ops to window borders always fall back
> > to software. It starts with miPaintWindow() - if it has to draw
> > outside the window's drawable in order to draw the border it requests
> > the screen pixmap which, thanks to the insane way in which it is
> > created by miCreateScreenResources(), is a DRAWABLE_PIXMAP without
> > further flags set so when miPaintWindow() calls ValidateGC() the resp.
> > DDX, be it XAA or EXA or whatever, thinks it's drawing into system
> > memory and falls back to software. The following patch fixes this for
> > XAA by checking the target drawable against pScreen->devPrivate and
>
> Use pScreen->GetScreenPixmap(pScreen) instead of pScreen->devPrivate. This
> may not be completely sufficient if the driver creates other "special"
> pixmaps (e.g. for an overlay), but I think the number of drivers that do
> that that also use XAA is zero.
>
Makes sense, in case someone or something hooks GetScreenPixmap().
> use accelerated ops if they match.
>
> I'm a little worried that this will break some drivers that expect
> accelerated pixmaps to have driver-provided devPrivates attached. I don't
> know offhand of any drivers that do that, but it is a change in behavior.
>
These drivers would hook CreatePixmap(), wouldn't they? That's still being
called.
> Index: xaaGC.c
> > ===================================================================
> > RCS file: /cvsroot/xsrc/external/mit/xorg-server/dist/hw/xfree86/xaa/
> > xaaGC.c,v
> > retrieving revision 1.1.1.2
> > diff -u -w -r1.1.1.2 xaaGC.c
> > - --- xaaGC.c 11 Jun 2009 01:52:58 -0000 1.1.1.2
> > +++ xaaGC.c 24 Sep 2009 21:06:10 -0000
> > @@ -88,7 +88,8 @@
> > pGC->fgPixel = 0x7fffffff;
> > }
> >
> > - - if((pDraw->type == DRAWABLE_PIXMAP) && !
> > IS_OFFSCREEN_PIXMAP(pDraw)){
> > + if((pDraw->type == DRAWABLE_PIXMAP) &&
> > + !IS_OFFSCREEN_PIXMAP(pDraw) && !PIXMAP_IS_SCREEN(pDraw, pGC)) {
> > pGCPriv->flags = OPS_ARE_PIXMAP;
> > pGCPriv->changes |= changes;
> >
> > Index: xaalocal.h
> > ===================================================================
> > RCS file: /cvsroot/xsrc/external/mit/xorg-server/dist/hw/xfree86/xaa/
> > xaalocal.h,v
> > retrieving revision 1.3
> > diff -u -w -r1.3 xaalocal.h
> > - --- xaalocal.h 11 Jun 2009 02:13:52 -0000 1.3
> > +++ xaalocal.h 24 Sep 2009 21:06:11 -0000
> > @@ -1710,6 +1710,9 @@
> > #define IS_OFFSCREEN_PIXMAP(pPix)\
> > ((XAA_GET_PIXMAP_PRIVATE((PixmapPtr)(pPix)))->offscreenArea)
> >
> > +#define PIXMAP_IS_SCREEN(pPix, pGC)\
> > + (pPix == pGC->pScreen->devPrivate)
> > +
> > #define PIXMAP_IS_SHARED(pPix)\
> > ((XAA_GET_PIXMAP_PRIVATE((PixmapPtr)(pPix)))->flags &
> > SHARED_PIXMAP)
> >
> >
> > this isn't really a performance issue but there are graphics chips
> > which don't let us map their framebuffers in a useful way ( think SGI
> > newport and crime for example ) where we really don't want anything to
> > fall back to software if there is any other way.
> >
> > A proper way to fix this would be to change the way the screen pixmap
> > is created so the accel lib, be it XAA, EXA or whatever, knows what
> > it's doing and can mark the pixmap as in video memory. As it is now
> > miCreateScreenResources() just calls CreatePixmap() with the right
> > depth but no width or height, then fills in geometry, data pointer and
> > so on.
>
> Drivers can plug whatever else they need into the screen pixmap by wrapping
> CreateScreenResources.
>
Maybe XAA should do that. Otherwise, what business has mi knowing about the
address of mapped video memory?
have fun
Michael
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.x.org/archives/xorg-devel/attachments/20090924/e1e3188d/attachment.html
More information about the xorg-devel
mailing list