[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