<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 TRANSITIONAL//EN"> <HTML> <HEAD> <META HTTP-EQUIV="Content-Type" CONTENT="text/html; CHARSET=UTF-8"> <META NAME="GENERATOR" CONTENT="GtkHTML/3.3.2"> </HEAD> <BODY> On Thu, 2005-10-13 at 10:37 -0700, Bill Kendrick wrote: <BLOCKQUOTE TYPE=CITE> <PRE> On Thu, Oct 13, 2005 at 08:42:23AM -0400, Terrell Prudé, Jr. wrote: > TuxType is known to use 73Mb/sec *per client* at 1024x768 at 16-bit > color. And your server's on 100BaseTX? No wonder you're having > slowness issues! :-) Does TuxType not have an option to disable background images, or do other tweaks to reduce the amount of blitting done on-screen? </PRE> </BLOCKQUOTE> Dunno, but I don't believe that background images are the issue. The issue is the number of changes to the screen inherent in playing a game like TuxType, TuxMath, Chromium, Doom/Quake, etc. The complexity of the image itself doesn't matter, as long as it doesn't change. TuxType, like Quake, simply has major, major amounts of simultaneous screen changes. That's what makes it so bandwidth-hungry. <BLOCKQUOTE TYPE=CITE> <PRE> What kind of bandwidth does Tux paint use? (Note: the upcoming 0.9.15 will default to 800x600 at 24bpp, whereas previous versions defaulted to 640x480, and always used 16bpp) </PRE> </BLOCKQUOTE> I guess that would depend on what's being done. If someone's making a lot of changes to an image in TuxPaint, then bandwidth usage will go up, depending on the number of changes to the screen that X11 has to make. It's not so much a TuxType/TuxPaint/TuxAnything issue as it is an X11 issue. Using the example of the (totally awesome, BTW) game Chromium again, that took up a lot of bandwidth as well. 10/100 NICs are so cheap these days that I'd say, from a network perspective, your decision of 800x600x24bpp is a good one. --TP </BODY> </HTML>