Crossfire Mailing List Archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: xpm slow?



>>>>[From Eric A. Anderson]
    
    Philip Brown <philb@soda.berkeley.edu> writes:
    > I disagree. The reason pixmaps are slow is because of X overhead.
    > the reason fonts ar quicker is because of font mechanisms to reduce X
    > overhead.
    > With client/server models, there wil be NO X overhead. hence no problem.

    All client/server will buy you is not having the X stuff running over
    long-haul networks; you'll still be doing X stuff to the local
    machine, which should have about the same performance as running
    crossfire and displaying it on the same machine.

Yes and no. You're neglecting the fact that almost any machine made &
designed in the last ten years should be able to handle blitting pixmaps
to the screen fast enough to be acceptable to crossfire play.


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

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.

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

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.