Re: GUI performance issues with images and scrollers

[Riccardo]

Hello,

On Friday, April 29, 2005, at 03:47 PM, Adrian Robert wrote:

> 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.

yes, I think this metric shows a similar issue to "high network traffic" 
since it shows that a lot of comunicaiton is being done to 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.

yes, I think that we see two inefficiencies here: one is common to both 
art and xlib (which will affect for example the slow window creation 
time) and one that affects xlib only. In fact I must correct myself: art 
is quite faster with images when used on a local server (I cited the 
remote display problem only as a "traffic" metric, not as a comparison 
to art, I know art is not optimized for remote display and never will 
be. I hope I don't generated misunderstandings here).

-Riccardo