On 2005-04-29 08:38:30 -0400 Riccardo <[EMAIL PROTECTED]> wrote:
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.
A simple but unexpectedly useful metric in my experience has been to run a 'top' in one window while putting an app through its paces. I was surprised to discover that most of the CPU during performance bottlenecks was not going to the app, but to X. This led me to investigate the interaction with the X server, and I found in my case that there was too much flushing traffic between the gnustep-maintained pixmap and the X server.
During Cocoa and gnustep drawing and image modification for the most commonly used backing-stored window type, there is an update phase, when an app memory pixmap is updated, and a flush phase, when the changes are sent to the window server. In gnustep, this is literally a flush of a rectangular area to the X server's memory; I'm not sure what the mechanics are in Cocoa/Quartz. In any case, in Cocoa, the docs say that a flush occurs but only for the minimal rectangular area surrounding the pixels actually modified. In gnustep, the modified area is not tracked explicitly, and the entire window will be flushed every time unless smaller rects are given in [view lockFocusInRect], which is a gnustep extension.
To get gnustep to behave like Cocoa would be a fair amount of work, implementing modified pixel area tracking for all low-level draw operations.
A second set of performance-affecting issues that might be affecting large images particularly surround memory management for images. In particular, how much of the image is kept in memory at one time, and where? For example, try comparing xv and eog (eye of gnome) on a large image. The determination of how much of the image to cache in the X server should be made based on the size of the image and available memory constraints. My impression of gnustep is that it does not implement multiple strategies but just caches the whole image in the X server every time. People who know more than I can say more, but I think fixing this would also entail a fair amount of work, though not so much as the modification area tracking...
Anyway, in sum I don't think having X in the loop is the problem, it's just the gnustep drawing / image management layer needs to get more sophisticated.
_______________________________________________ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev