Return to BSD News archive
Xref: sserve comp.os.386bsd.apps:1017 comp.os.linux.misc:10789 Path: sserve!newshost.anu.edu.au!munnari.oz.au!foxhound.dsto.gov.au!fang.dsto.gov.au!yoyo.aarnet.edu.au!news.adelaide.edu.au!news.cs.su.oz.au!harbinger.cc.monash.edu.au!msuinfo!uwm.edu!vixen.cso.uiuc.edu!howland.reston.ans.net!usenet.ins.cwru.edu!eff!news.kei.com!news.byu.edu!cwis.isu.edu!u.cc.utah.edu!cs.weber.edu!terry From: terry@cs.weber.edu (Terry Lambert) Newsgroups: comp.os.386bsd.apps,comp.os.linux.misc Subject: Re: DOOM for X Date: 14 Mar 1994 02:12:58 GMT Organization: Weber State University, Ogden, UT Lines: 55 Distribution: inet Message-ID: <2m0h7a$3ck@u.cc.utah.edu> References: <hastyCMGpA7.Gu5@netcom.com> <2lo4m0$sdt@bosnia.pop.psu.edu> <SJA.94Mar12174713@gamma.hut.fi> NNTP-Posting-Host: cs.weber.edu In article <SJA.94Mar12174713@gamma.hut.fi> sja@snakemail.hut.fi (Sakari Jalovaara) writes: ]> I agree that X the wrong platform for doing high-speed and ]> time-critical graphics applications like video-style games. There are ]> extensions (not SHM) that help a little, but there are lots of ]> advantages to taking direct control of the hardware. The result is ]> _not_ client-server. ] ]To get high speed graphics on X you just need to re-write the server: ] ] - At program startup, map the X server code into the application ] program memory space (e.g. as a shared library). ] - In every Xlib call, check if the display to be accessed is local. ] If not, send a network X request as usual. ] - For local displays, call the appropriate routine in the server. ] The server code should be extended to do appripriate locking ] for its global data and display hardware. There are (apparently) several misconceptions here. (1) You can't necessarily map memory from the display adapter directly. There is often a "window" which you must use to communicate with display memory that would be used instead. (2) Not all OS's support the large segment changes, where the segment size no longer matches the page size directly to allow you to map more than 4k at a time (SVR4 does, though). (3) The client/server distinctions are fictional; I have a lab full of NCR X terminals (now an AT&T X terminals I guess) that support developement and download of clients to run in the terminal (server) address space. Thinking about it a minute should convince you that this is the only way to do a window manager, and an enlightened programmer would probably implement an RPC mechanism for widget drawing the same way so that look-n-feel(tm) would rely on which window manager got downloaded. Another issue in most X programs is that the programmers don't know what defines "fast", or they are too worried about blowing bits to screen memory directly to do things so they can be fast on remote X terminals as well. This is generally reflected by the use of bitmaps and pixmaps (which must be shoved over the wire and are generally in ancillary memory in the server) instead of, for instance, fonts, which are generally stored in a font cache in video memory and can be blitted into place by a single card function. It's quite possible to build *fast* X games on relatively low speed hardware if you do it the right way. Terry Lambert terry@cs.weber.edu --- Any opinions in this posting are my own and not those of my present or previous employers.