Return to BSD News archive
Xref: sserve comp.os.386bsd.apps:1029 comp.os.linux.misc:10869 Path: sserve!newshost.anu.edu.au!munnari.oz.au!news.Hawaii.Edu!ames!hookup!news.kei.com!bloom-beacon.mit.edu!senator-bedfellow.mit.edu!dmuir From: dmuir@ATHENA.MIT.EDU (Douglas Muir) Newsgroups: comp.os.386bsd.apps,comp.os.linux.misc Subject: Re: DOOM for X Date: 11 Mar 1994 18:41:52 GMT Organization: Massachusetts Institute of Technology Lines: 46 Message-ID: <2lqe1g$1k5@senator-bedfellow.MIT.EDU> References: <hastyCMEw58.FMr@netcom.com> <2lm9ih$6s5@godot.cc.duq.edu> <glen.763349922@paladine> NNTP-Posting-Host: carbonara.mit.edu In article <glen.763349922@paladine> glen@paladine.ece.jcu.edu.au (Glen Harris) writes: >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....... > I haven't seen a more authoritative (i.e., from the XFree86[tm] team) response, so I'll jump in with my understanding of the situation. The XShm extensions do *not* directly map a bitmap in memory to the framebuffer memory on your video card. As far as I know, that is just plain not possible (disregarding the 64k window to video memory on most cards, memory can only be mapped in 1 page (4k) chunks, meaning it could only work if you had a 4096 pixel wide bitmap at 8 bits of depth). What the XShm extensions do is set up a region of shared memory between the X server and the client program. In a "normal" X program, when you draw an image (using XPutImage, or the equivalent Pixmap function, which I don't recall offhand) the client library sends the image data to the server via the underlying communication method (usually a unix domain or inet socket), the server builds a copy of the bitmap in its own address space, and then bltblts the copy to the screen. (The client library also takes care of the 256k limit on the size of a protocol request by breaking up the data into multiple packets if required). In a "shared image" X program, after you've set up the shared memory segment between the client and server, using XShmPutImage (I think that's it) simply tells the server to bltblt the shared memory to the screen. How much faster this will be really depends on how bad the communications overhead is in the "normal" case. If the communications overhead is only 5% of the total time needed to draw the image to the screen (i.e., you have fast sockets but a slow blitter) then XShm won't get you that much. If you have slow sockets and a fast blitter, though, XShm can greatly enhance performance. -Doug Muir