XCreatePixmapCursor stats a lot of files...

[BJörn Lindqvist]

On 10/2/07, Lubos Lunak <l.lunak at suse.cz> wrote:
> On út 2. října 2007, Glynn Clements wrote:
> > No, it's a bug, insofar as it contradicts the documentation of
> > XCreatePixmapCursor() as well as existing behaviour. Also, it appears
> > that there is no way to override it and *force* Xlib to do what it's
> > told.
> ...
> > >  The fact that the cursor theming is pretty inefficient is a different
> > > matter though :(.
> >
> > The inefficiency isn't the problem. The fact that it's happening at
> > all is the problem. If the client tells Xlib to use a specific pixmap
> > and mask as the cursor, Xlib should damn well do what it's told, not
> > ignore the client and use some other cursor.
>
>  So you actually got some other cursor than you asked for? I shouldn't think

It should be pretty easy to inject a different cursor by writing
appropriate data to
/usr/share/pixmaps/Human/cursors/00000000000000000000000000000000 for
example for the strace I posted.

> so, I'd expect that in your specific case it did exactly what you expected,
> minus some hidden inefficiency which, as you say, isn't a problem for you.

Which apps are helped by this feature? AFAICT, no GNOME apps use it.
Why can't those apps that rely on this behavior be fixed? Surely,
calling XCreatePixmapCursor() and expect to get a themed cursor cannot
be the canonical way to do it, can it?

And the inefficiency is a real problem for me. 150 ms on a decent
laptop easily becomes seconds on low-end hardware if you have other
processes and disk activity running. What if your home directory is
mounted on a NFS share when XCreatePixmapCursor() goes looking in
~/.icons? Even more overhead.

I don't feel comfortable having to pay the performance price for
something that, frankly, is an ugly hack. I think it is quite unfair.

-- 
mvh Björn