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

Re: xpm slow?



 The screen redraws will be slower than using bitmaps or fonts.  Fonts,
in genral, should be very quick, simply because of the tranmission method
to draw them.

 Bitmaps should be a little slower, with pixmaps the slowest.

 The re-do of the pixmap code to prevent flickering and stuff may make them
slower if people are playing remotely, but I am not sure.  I think it depends
more on how the XServer handles stuff like that over links.

 The old method draw the background pixmap and then the foreground
pixmap directly to the map (changing the clipmask and clip origin of the
gc before drawing each pixmap.)

 The new method creats a couple more gc's, and draws the background
to a temporary pixmap, sets the clipmask for the foreground pixmap, draws
that to the temporary pixmap, and then draws that pixmap to the screen.

 Each draw operation has its own gc.  This method saves one set clip
origin and 1 set clip mask.  However, it does one more draw (the cost
of the gc's should be pretty low I think.)

 I actually compiled my local version of crossfire with profiling
information in it.  I haven't looked over it carefully, but from the
one run I did, it looks like the draw function consumed a pretty low
amount of CPU time comapred to most of the rest of the code.

 However, XPM code probably consumes more time for the XServer.  And
depending on how loaded the X server is (or the machine it is running
on), and how synchronizing of flushign works, I could see this slowing
things down.

 However, with client server, this should not be a problem.  And I
don't know if I really want to dig into the X output code that much, if
client server is gong to happen sometime soon.  One of my ideas
regarding that was for functions that what keyboard input to call
another function with a function as a paremeter.
(ie, set_input_function(foo_bar), where foo_bar is a function.)  Then
when keyboard input is received, foo_bar is called with taht input
(two modes, key mode, and line mode.)

 This would eliminate the various input states stored in the player
structure.  IT would also make functions that want more input a lot
easier.  But if client/server happens, a lot of that code may become
irrelevant.

 --MArk