GUI performance issues with images and scrollers

[Riccardo]

Hello,

(this is my first post here into -dev, but I bet several of those who 
dwell here follow -discuss too)

I read today the extensive and excellent report of Tiger on Ars Technica 
which uncovered the 2d drawning improvments done in Quartz, both in 
software and using the GPU as well as other speed ups. This gave me the 
necessary energy of writing an email here about gnustep performance 
instead.

Shortly, I'll discuss my personal experience with very bad GNUstep 
performance when dealing with images and/or scroll views. I gather this 
mainly from PRICE, the application I write and maintain which displays 
images in a scroll view. But the same goes for other applications like 
preview, image viewer.. but also other applications as I will explain.

The window with the image loads unacceptably slow, even on a very fast 
computer and takes some time to draw. Scrolling it becomes rapidly a 
pain as the size increases. I'm not speaking of gigantic images. On a 
dell laptop with centrino, 600x600 is already noticeably slow and 
1024x768 is really jerky when moving the scroll thumbs. Interestingly, 
reducing the window size to 600x600 doesn't help very much, so driving 
itself is probably not the biggest bottleneck, as further considerations 
below will show. Making the window really small, like showing 300x300 
pixels makes things noticeable faster but still jerky.

I have some machines running the art backend and the rest run xlib. I 
can't notice a really big difference (also due to different hardware), 
although art seems to me a littlebit faster.

I have run tests on x86 style hardware. The laptop I used runs gentoo on 
a centrino, latest kernel and xorg with DRI for my graphics card, a 
radeon, enabled, every binary optimized, uses xlib. For GTK or motif or 
other applications this box is really fast. I tried also on FreeBSD on a 
pentium II 266, ATI drivers on a rage... things are slower about 
proportionally to what you would expect from the hardware. alsy a cyrix 
686 was tested this time with libart on an s3 trio which ends performing 
simpilarly to the PII.

An interesting comparison yields my old powermac 9600: it runs Puma 10.1 
macos on an unsupported ATI card: that is the whole quartz and 
compositing is done in software. of course drawing is slower than it 
should, but still much, much smoother and faster than any gnustep setup 
I tried, hardware wise cpu and video board sre just slightly superior 
than the PII setup (address@hidden, ATI Rage LT)

the gnustep problem becomes even more evident when running on solaris 
for example or on MkLinux where I still have Xfree 3: the performances 
are unusable. Generally it seems that x86 hardware performs better...

Another aspect can be seen when exporting the display to another host (I 
tried this with xlib only lately): opening an image window is VERY slow 
(up to a minute!) and scrolling too! and the network loads goes very 
high. COmparably many gtk applications are much faster, you can almost 
use GIMP over a 10mbit network and using small dedicated viewers like xv 
is a breeze. SO I really Don't understand where the bottleneck is. Motif 
can be even faster sometimes. So I really wonder...

I don't know much of the -gui and -back workings, but from the above 
experiences it seems to me that the problem is in the image handling 
itself and less dependend from the backend (although xlib proves a bit 
slower than art when used locally on a fast videocard).

Opening a large window in GWorkspace full of icons and scrolling them 
seems to be faster than an image of about the same size

I hope I have pointed to a problem that other feel or reproduce and I am 
not interested in answers like "hey, we must pass through X macosx must 
not" or so. I know this. I hope that this could lead to a search for the 
bottleneck or if it is already known to some improvements...

-Riccardo