pharris at opentext.com
Tue Apr 7 17:05:08 PDT 2009
Mark Wagner wrote:
> On Tue, Apr 7, 2009 at 15:37, Peter Harris <pharris at opentext.com> wrote:
>> Mark Wagner wrote:
>>> , such as drawing images? One of the big things I
>>> need to update is the toolkit's image-handling code: right now, a
>>> simple JPEG splashscreen takes seven seconds to draw.
>> Seven seconds! The last time I saw a splashscreen take that long to
>> draw, the app was doing a million XSetForeground/XDrawPoint pairs,
>> instead of one single XPutImage.
>> Without knowing exactly what you're doing, it is difficult to suggest
> I believe the slow part is a million calls to XAllocColor(). Since it
> works (if slowly), I haven't looked too closely at it. I've been
> concentrating on implementing features that are present in the Mac and
> Windows branches of the toolkit, but not the Linux branch.
Yes, a million XAllocColor calls will hurt, since each one costs a
round-trip. Over the network, that adds up to minutes. Even on a local
display, that's still two million context switches.
Unless you need to maintain support for legacy (PseudoColor) displays,
there really isn't a reason to call XAllocColor any more. Even if you do
need to work on a PseudoColor display, you're far better off allocating
a new Colormap and calling XStoreColors once (to fill the whole
Colormap with exactly the colors you need) for this sort of thing.
Hope that helps,
 Please don't call InstallColormap - that's for window managers. Try
both XSetWMColormapWindows (at the top level) and
XChangeWindowAttributes (on each window and subwindow that needs the
custom colormap). Yes, PseudoColor is a pain. Even more so on Windows,
although that's down to taste (much like clipboards). Fortunately,
PseudoColor seems to be mostly dead these days.
Open Text Connectivity Solutions Group
Peter Harris http://www.opentext.com/connectivity
Research and Development Phone: +1 905 762 6001
pharris at opentext.com Toll Free: 1 877 359 4866
More information about the xorg