Return to BSD News archive
Xref: sserve comp.os.386bsd.apps:1008 comp.os.linux.misc:10738 Path: sserve!newshost.anu.edu.au!munnari.oz.au!ihnp4.ucsd.edu!agate!howland.reston.ans.net!math.ohio-state.edu!cyber2.cyberstore.ca!nwnexus!ole!rwing!eskimo!orestz From: orestz@eskimo.com (Orest Zborowski) Newsgroups: comp.os.386bsd.apps,comp.os.linux.misc Subject: Re: DOOM for X Message-ID: <CMHpoL.F75@eskimo.com> Date: 11 Mar 94 07:48:10 GMT References: <1994Mar3.131137.27311@infodev.cam.ac.uk> <CM44Lq.78x@seagoon.newcastle.edu.au> <2lkpg5$8hn@Tut.MsState.Edu> <hastyCMEw58.FMr@netcom.com> <2lm9ih$6s5@godot.cc.duq.edu> <glen.763349922@paladine> Followup-To: comp.os.386bsd.apps,comp.os.linux.misc Organization: Eskimo North (206) For-Ever Lines: 35 X-Newsreader: TIN [version 1.2 PL2] Glen Harris (glen@paladine.ece.jcu.edu.au) wrote: : In <2lm9ih$6s5@godot.cc.duq.edu> mcquill@next.duq.edu (Tod McQuillin) writes: : >Amancio, what effect, if any, do you think the shared memory extentions of X : >have on graphics performance? : What it means is that a bitmap in memory is mapped directly over the : screen, so an access to the array is an access to the screen. After the : mapping is set up, there's no calls to X for the graphics. In effect, : it's exactly as if you were in dos, but there's no 64Kb segment switching : as the system does this transparently. *I* don't know how page flipping : is done, maybe there's a X call to do this, or a fast memcpy during the : refresh? Inquiring minds....... This isn't exactly correct. The MIT_SHM extension allows the client and the server to share the memory associated with an XImage or Pixmap. This means there is no need to communicate the bits between the server and client. The server will use this Pixmap (the XImage gets turned into a Pixmap in the server) as a source, as if a normal XImage had been created. The savings can be enormous, as you can tell from running mpeg_play with and without shared memory support. This doesn't mean that server video memory is mapped into the client's address space. That wouldn't make much sense, as the client would have to know as much about manipulating the video board as the server does, and in XFree86 this knowledge is substantial. That's the tradeoff: by providing a unified API, the client can take advantage of a variety of hardware, but at a cost of implementing this API by the server. By cleverly taking advantage of shared memory to reduce net traffic, and other properties of client/server relationships, the client program can be more effective than if in control over everything, if only in terms of complexity. But you can never get the same performance as with dedicated systems that manipulate video boards directly. -orest