CVS Update: xc (branch: trunk)

[Thomas Winischhofer]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Thomas Winischhofer wrote:
> Thomas Winischhofer wrote:
> 
>>>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 gabe.freedesktop.org	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
>>>good...
> 
> "time cat init301.c init301.c init301.c init301.c" in the console
> (konsole) went from 1.3 to 1.5 seconds averagely.

Nope, the exaGlyph can't be it, since I don't support the composite
hooks (yet).

Some migration logic is borked as it seems.


- --
Thomas Winischhofer
Vienna/Austria
thomas AT winischhofer DOT net          http://www.winischhofer.net/

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFDLWADzydIRAktyUcRAtqMAJ9uNMptmdbgD6EFIv6S2lXHZByDFgCdFzCJ
Pezjqobfvh78EuvQlJhfr4w=
=6kDP
-----END PGP SIGNATURE-----