nanogui: Shared memory + SDL
Subject:
Re: Shared memory + SDL
From:
"Greg Haerr" ####@####.####
Date:
26 Feb 2000 20:35:55 -0000
Message-Id: <013a01bf8097$74c2be40$15320cd0@gregh>
: What I want is for the client to be able to allocate a shared off-screen
: buffer that it can do whatever it wants with, and then do a call
: to the server to make the *server* blit the off-screen buffer onto the
: screen.
Oh, I get it now. Neat idea.
: I'll try to get time to do some work on it this weekend.
Please use
ftp://microwindows.censoft.com/pub/microwindows/microwindows-0.88pre1b.tar.gz
as the source; I've recently rewritten again the low level screen drivers for
speed. No more double procedure calls, etc.
:
: Some people here have suggested that we let the client allocate and specify
: the area to use for the off screen buffer, since some libraries etc. want
: to allocate memory themselves, rather than get it from a client.
Check out my new screen driver entry points for off-screen drawing.
There's an AllocMemGC for actually allocating an off-screen driver,
then a MapMemGC for initializing the drawing area, and a FreeMemGC
for freeing the PSD structure. The MapMemGC call takes a user-specified
address for the actual drawable bitmap. You get to choose in the API
implementation whether to have the client or the API alloc the bits...
:
: My suggestion is thus to add a GrNewPixmap(), GrNewOffscrenWindow() or
: GrNewDrawable() or something to indicate an off screen drawable (any
: preferences?)
GrNewPixmap()
that take as argument a pixel type (so you can choose whether
: you want the same as the hardware or PF_RGB or whatever), width, heigth,
: and optionally a memory area that it arrange for the server to share.
:
: The only other thing to do then is to add GrBlit() to the client library...
I still think that we should get the regular off-screen drawing working in
Nano-X first. Would you like to do that? Basically, add GrNewPixmap,
which allocates an id. Then, modify GsPrepareDrawing so that it
returns either the screen psd or the appropriate offscreen psd. (remove
the global psd in srvfunc.c) Thus, all the drawing routines will draw
on the screen or offscreen. Then add the blitter, which should probably
be called GrCopyArea (use same parms as GdBlit).
You should probably add a GrDestroyPixmap
as well.
:
: Of course it would be interesting to look at optimized support for shared
: memory drawables for some other parts of the client library as well (GrArea()
: and GrReadArea() at least), but I think that's less important at this point.
: The greatest advantage of shared memory support is that it allows applications
: that already draw in an off screen buffer in a suitable pixel format to vastly
: reduce data copying and the number of context switches.
:
If you decide to add shared memory support, please enable/disable that
with a config file option. Not all systems support it, so we've got to
be able to turn it off ;-)
Regards,
Greg
