[CF-Devel] sdl client

Mark Wedel mwedel at sonic.net
Thu Oct 18 21:54:09 CDT 2001


Tim Rightnour wrote:

>
     
      Well..  another possible solution is to just make only two clients.  Personally
     
     >
     
      I like the GTK client, and am loathe to give it up, but willing to if we can
     
     >
     
      only have one.  If we can't do that.. perhaps we can at least drop the number
     
     >
     
      to two?
     
     
 Two is better than 6. But I think a lot of this really depends on what someone
is willing to suppport.  For example, if someone said that they would keep the
java client up to date, and actually did that and made necessary changes to keep
it working (and doing things like noticing the proposed protocol changes and
updating the java client so when those changes actually got integrated, the java
client was all ready to go), I don't think people would complain that much.

 Yes, this still results in duplicative efforts.  But if someone is actually
willing to take responsibility for maintenance and upkeep of a client, I think
it will be difficult to tell them 'no, don't work on that client, work on this
one instead.'

 So what may be helpful is a list that contains the clients, who (if anyone) is
maintaining it, and its current status (support/unsupported but works to x
extent).  This should be on an easy to find web page.  If person claiming
support stops working on it, it goes into the unsupported list.

>
     
     
     >
     
      Off topic.. but speaking of the GTK client..  I'm convinced it has a serious
     
     >
     
      memory leak.  Every time I run it, my xserver gets bigger, by alot, has anyone
     
     >
     
      else seen this?  (xf3.3.6)
     
     >
     
     
     
 It has a known memory leak in the message windows (the ones the text gets drawn
to).  Text here only grows, and is never removed.

 I tried adding calls to the proper GTK functions to remove text - this works
about 99% of the time, but the 1% it doesn't work, it causes the client to
crash.  I'm convinced that is a gtk library problem.

 It may very well leak pixmaps or other data, but I would think/hope the
x-server would realize the app using those has done away, and it should free
those up.


 Just as a data point, I did some timing between the gtk client (using native
gdk images) and the gtk client using sdl to draw.  The timing was only for the
actual generation of the map (Basically, time calls put at the start and end of
the map gen function).

 SDL was much slower on my system (dual p3-500).  For a 15x15 map, it took
around 100 ms (going higher if per pixel lighting is used and going to a map
with such lighting).  In most cases, the gtk drawing routine was less than 10
ms.  Being the gtk also uses x pixmaps, this performance is probably pretty good
a remote display (ie, xterm), compared to the sdl drawing mode.  This is just to
put some more concrete numbers as one of the previous messages did mention
drawing speeds.

 Note that this does not really say anything about the SDL client - it may draw
faster - I haven't tried it.

    
    


More information about the crossfire mailing list