CVS Update: xc (branch: trunk)

Thomas Winischhofer thomas at
Sun Sep 18 05:16:03 PDT 2005

Hash: SHA1

Eric Anholt wrote:
> On Sat, 2005-09-17 at 13:02 -0700, Eric Anholt wrote:
>>CVSROOT:	/cvs/xorg
>>Module name:	xc
>>Changes by:	anholt at	05/09/17 13:02:02
>>Log message:
>>  - Don't try to upload 0 byte-per-pixel (PICT_a1) data using
>>    RADEONHostDataBlit.
>>  - Disable the shortcut for switching from 3d to 3d in radeon_exa.c.  It
>>    appears that we do need the cache flush here, thought it's not clear
>>    why.  Disable the 2d to 2d shortcut while here, since I'm unsure of
>>    what we're doing.  Exposed by the following bit:
>>  - Bug #4485: Add a new routine, exaGlyphs, to handle font drawing.
>>    Glyphs were being accumulated in from non-migratable scratch pixmaps,
>>    causing the destination pixmap to move towards screen but the
>>    migration necessary for source never to happen, leading to abysmal
>>    performance.  Instead, copy the scratch glyph data into a real pixmap
>>    first, then composite from that into the destination, allowing for
>>    migration.  time ls -lR from programs/Xserver showed 26.9% (+/- 6.3%)
>>    decrease in wall time (n=3).
>>  - Create exaDrawableUse* wrapping exaPixmapUse*, but which are aware of
>>    windows needing backing store.  Makes migration code prettier, and
>>    ensures that composited windows will be migrated as normal when we
>>    turn off cw for EXA. (issue brought up by keithp)
> We had a discussion on IRC about the cost of item 2, disabling the
> shortcut for "switching" from 2d to 2d or 3d to 3d.  I decided to test
> this, using the same ls -lR, against the theoretical best of never
> having to do the syncing (stick a break at the top of
> RADEON_SWITCH_TO_*).  It was clear that fonts were broken when I made
> this change.  At n=7, a=.05, caches hot, there was no statistically
> significant difference.  In this case, I'm quite happy with the code as
> it is and feel no need to try to squeeze hypothetical performance out by
> being stingier with the flushes :)

Whatever you did, these changes (glyph stuff supposedly) make scrolling
non-AA text (which I use for console and text editor) on sis hardware
visibly slower. Scrolling though a text file in the editor (kwrite, in
my case) using the scroll bar or the mouse wheel lags *quite* a bit. No


- --
Thomas Winischhofer
thomas AT winischhofer DOT net

Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird -


More information about the xorg mailing list