Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!csd4.milw.wisc.edu!leah!rpi!batcomputer!cornell!rochester!pt.cs.cmu.edu!f.gp.cs.cmu.edu!dac From: dac@f.gp.cs.cmu.edu (Daniel Christian) Newsgroups: comp.windows.x Subject: Re: A Thought on X Terminals Message-ID: <4424@pt.cs.cmu.edu> Date: 7 Mar 89 00:59:36 GMT References: <8903011944.AA04616@torel.uit.no> Organization: Carnegie-Mellon University, CS/RI Lines: 35 I agree with the Visual folks when they say that we need to look at how we write X applications. I do not beleive that virtual memory should be required for day-to-day applications (which in my book is almost everything except serious CAD type work). It is not unreasonable to have limits in the server and keep these limits in mind when designing applications. All personal computer applications have dealt with limits like these very effectively. Applications need to be efficient. Inefficiency unnecessarily strains the server and slows down the system. Toolkits were originally billed as being more efficient than simple Xlib code. Is this really true? What more can be done? From doing some server development, I noticed that toolkit applications imeadiately store one or more images to the server. As far as I can tell, these images are not use except maybe as border stipple. I haven't dug into the toolkit code enought to know what it is trying to do. There are a large number of people out there who would like to use their current PC/Mac/Amiga/etc as an (cheap) X server. The installed base of these machines absolutely dwarfs the workstation market: Do not ignore them. Many people will wonder why a machine that currenly runs a huge number of complete graphics applications is suddenly too small to handle just the graphics side of X applications. On a similar note, why are toolkit applications so @#$%&#!@# Large?! The baseline seems to be about 240K on a Sun3 (Xlogo). xfd is 100K smaller and does more. Do things get smaller with C++ tookits? -Dan Christian dac@ri.cmu.edu All disclaimers apply. --