[patch] drawing window borders always falls back to software

Michel Dänzer michel at daenzer.net
Thu Sep 24 15:19:14 PDT 2009

On Thu, 2009-09-24 at 17:45 -0400, Michael wrote: 
> On Sep 24, 2009, at 5:29 PM, Michel Dänzer wrote:
> > On Thu, 2009-09-24 at 17:10 -0400, Michael wrote:
> >>
> >> 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.
> >
> > I haven't seen any problems like this with EXA - otherwise it couldn't
> > accelerate any operations on the visible screen. If you've actually  
> > seen
> > such a problem with EXA, I'd be interested in more specific  
> > information
> > about that.
> This happens only when drawing borders outside of DRAWABLE_WINDOW, so  
> it bites xterm and a bunch of Xaw widgets but not much else. You  
> probably wouldn't ever see it if you use KDE or GNOME. Also, you  
> wouldn't notice unless drawing by software into the screen pixmap had  
> severe side effects.

Again, TTBOMK EXA doesn't have any problem with acceleration on the
screen pixmap - the driver interface only deals with pixmaps, so at that
level it couldn't even tell the difference between a window and its
borders if it wanted to. ;) Do you have any actual evidence to the

Earthling Michel Dänzer           |                http://www.vmware.com
Libre software enthusiast         |          Debian, X and DRI developer

More information about the xorg-devel mailing list