[patch] drawing window borders always falls back to software

Michael macallan at NetBSD.org
Thu Sep 24 18:21:16 PDT 2009

Hash: SHA1


On Sep 24, 2009, at 6:19 PM, Michel Dänzer wrote:

> 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
> contrary?

Ah, now I see how EXA gets around this particular problem. I don't see  
any special treatment for 0x0 pixmaps in exaCreatePixmap() and the  
decision wether to use acceleration or not is, unlike with XAA, made  
on a case-by-case basis, not in ValidateGC(). There it calls  
exaPixmapIsOffscreen() which checks the pixmap's address against the  
range of mapped video memory.
So, yeah, EXA is unaffected. Unfortunately I can't do that on some of  
my hardware since there's no mappable (useful) framebuffer. Which is  
also one reason why I can't switch to EXA - not all hardware made for  
X11 can work like EXA wants it to.

have fun

Version: GnuPG v1.4.7 (Darwin)


More information about the xorg-devel mailing list