[CF-Devel] GTK Client performance

[Mark Wedel]

Kevin R. Bulgrien wrote:
>
     
      GTK Client 1.3.1
     
     >
     
     
     >
     
      Ok, well, I know that my system is memory challenged, but this seems
     
     >
     
      ridiculous...
     
     >
     
     
     >
     
      A room full of creatures like in the mushroom quest absolutely kills my
     
     >
     
      character... not because I can't fight, but because the client slows to
     
     >
     
      a crawl...   Keypresses seem to be processed at a rate of less than one
     
     >
     
      per second.  Before you know it, apparent lags of several minutes can 
     
     >
     
      occur because of buffered keypresses...  Then you lose track, and cannot
     
     >
     
      recover because it is very hard to get to the point where you know it is
     
     >
     
      processing current requests.
     
     
  <rest snipped>

The basic model for client/server communication is that the server tells the 
client what is on each space.  IT is then the clients responsibility to then 
draw it.  The performance of one client doesn't effect the server in any way - 
the server sends the data.  If the client falls too far behind (to the extent 
that the servers buffers for the client fills up), the server drops the connection.

  The client currently has no logic in the client to deal with slow systems.  In 
practice, each 'tick' on the server is 120 ms (and so the server sends a map 
update to the client that often).  If it is taking the client 200 ms to process 
that data, it is losing 80 ms/tick.

  Certainly gtk drawing is not the most efficient.  SDL _may_ be faster.  The 
main advantage in most case with SDL is that it is easier to do better effects. 
  There is some way to have SDL use the DGA extension by setting some 
environmental variables and running as root.  I never really tried that out - 
most DGA stuff worked oddly on my dual headed system.

  The difference settings on darkness in general probably won't effect 
performance unless the map you are actually is a 'dark' map that is using 
lighting/darkness.  There aren't a lot of maps out there using that.

  As a note, you can run the client with the '-timemapredraw' command line 
option.  This will print out timing information on how long it takes to render 
the map - this data is printed to stdout from whatever window you run the client 
from.  This can give you some concrete numbers, as well as let you see how 
changing the different options effect the draw time.

  Looking at your settings, things to improve performance:

Turn of fog of war.  Reduces number of space the client may have to draw (this 
may not do much depending on the map - eg, if the entire group of monsters is 
visible, fog of war isn't doing much).

   Reduce the mapscale.  The scaling isn't a factor (that is only done when the 
image is first downloaded and rendered), but larger scale (you have 125) is more 
bits that the client has to draw.  Having the scale at 125 basically means there 
  is 56% more data is has to draw/space.

  Reducing the map width/height can also help, but your running at 12x12 - Going 
much lower reduces play experience.  But fewer spaces is also less stuff to 
draw, but also less data the server sends, and less data the client has to 
prcess (eg, update what is on each space).  But almost certainly, it is the cost 
of rendering that is the problem.

  The client could certainly be more clever in terms of how it deals with the 
data.  Eg, if it knows it took 200 ms to process that map draw, it could supress 
the next one - basically, draw on every other tick.  This would result in the 
map perhaps not being really correct, but at least it would be up to date and 
reduce lag.  There may be some additional cost in skipping the draw for the 
cycle (there could be more spaces to update the next cycle than otherwise), but 
it would probably be a win.