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.