Lex,

Please check that you're actually running one of the accellerated versions
of xfree86 - there are huge speed differences. The 32bit display depth
shouldn't matter as much (except for 16 bit since this is where the hard fun
goes); here are my results running on 1024x768x32 (PII/400, Win98, ATI Rage
LT)

32   26  27  26  27  
16   90  90  92  93
8   33  33  33  33  
4   30  30  29  31  
1   20  20  19  20  

Except from the 16<->32 bit conversions it's all in the range of 30-40 fps
which is as it should be on a hardware like this.

BTW, if anyone is *really* interested in this issue here is something to
play with. Inplace pixel conversion. E.g., rather than allocating an extra
pixmap you go on and reverse bytes/words or change color components directly
in the display bits. The Win32 VM does it and it is rather effective. I
think that this is actually due to increased cache coherence - the initial
reversal pass will load pretty much all of the image data into L2 RAM so
that actual data transfer to the screen and the post-reversal step all come
from the cache.

  - Andreas

> -----Original Message-----
> From: Lex Spoon [mailto:lex at cc.gatech.edu]
> Sent: Wednesday, March 22, 2000 9:15 AM
> To: squeak at cs.uiuc.edu
> Cc: recipient list not shown
> Subject: RE: Display Update Speed
> 
> 
> 
> Okay, I was actually testing without -xshm.  Here's a broader spread,
> based on Bob Jarvis's code:
> 
> >> without -xshm:
> >> 
> >> 32:   181  180  178  174  
> >> 16:   234  231  229  223  
> >> 8:   210  220  219  213  
> >>
> >> with -xshm:
> >>
> >> 32:   179  72  70  152  
> >> 16:   126  126  128  134  
> >> 8:   125  112  115  111  
> 
> 
> So it's close to twice as fast with -xshm.  But even so, it 
> still takes
> at least 100 ms in almost all combinations.
> 
> By the way, this is a 32-bit display (xdpyinfo says depth=24, bpp=32),
> so that might explain why some people are getting faster results.
> 
> 
> And incidentally, I just realized the VM I have doesn't work 
> with -xshm
> where Squeak and the display are both 32-bit. :(  The screen just goes
> black when I try it  (so interpret the 32-bit numbers with 
> -xshm with a
> grain of salt :)).  I have no idea if this has been fixed 
> more recently,
> and since I don't do much graphics stuff, I'm going to leave it alone
> for now.
> 
> 
> 
> Lex
>