Re: xpm slow?

[Niilo Neuvo <>]

Philip Brown writes:
>On the other hand, removing the bandwidth drag from the server handling
>multiple player X updates should help bunches.
>
>On my sparc _1_, running the old crossfire server in single-user mode
>pixmaps was acceptable. Slower than fonts, yeah. but we should be able to
>compe up with something.
>
>    Can we make it as fast as fonts?  No.
>
>You're neglecting the fact that we can do strange MIT-SHM stuff with
>local clients!!

There is no way you can draw a font character faster than using a
fixed size pixmap with memcpy/bcopy.  Assuming you don't have hardware
that is specialized in fonts, in which case your graphics probably are
fast enough to run crossfire anyhow.

>Well, okay, I know that doesn't help much when you have the pixmaps already
>defined. it helps most for defining the pixmaps. But there's gotta be
>tricks you can use , if you have a GUARANTEED local client.

Actually it does help.  We know that we don't have to worry about
clipping, gc's and all the other X stuff.

>Being limited to fonts of depth 1 just is too sucky for words.

Must agree here too.

>Perhaps someone should write an X program to compare speeds of
>the following things:
>
>refreshing a 10x10 pixmap grid each update
>  VS
>using MIT-SHM to draw into a single large pixmap, and blasting that each
>update.

>Any volunteers? MIT-SHM handling is definately NOT my strong point.

If someone writes the client/server split and does the standard Xlib
pixmap drawing, I can add the MIT-SHM handling.  This can be an option
that is only used if you are running X locally.

++Anipa