[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: GUI performance issues with images and scrollers
From: |
Riccardo |
Subject: |
Re: GUI performance issues with images and scrollers |
Date: |
Wed, 4 May 2005 23:15:36 +0200 |
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
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- Re: GUI performance issues with images and scrollers,
Riccardo <=