nanogui: Shared memory + SDL
Subject:
RE: Shared memory + SDL
From:
####@####.####
Date:
26 Feb 2000 11:39:49 -0000
Message-Id: <20000226112928.29874.qmail@nameplanet.com>
On Fri, 25 Feb 2000 10:16:38 -0700 Greg Haerr ####@####.#### wrote:
>:Why? GdBlit() does full clipping, doesn't it? So I can't see why
>:you shouldn't be able to use GdBlit() to blit from a shared memory
>:off screen device and directly onto screen.
>
>GdBlit requires the server's clip rectangle data in order to clip,
>that's all. If a client want's to blit directly, it's got to have
>the clip data; this is normally kept on the server.
I see know why we've talked past eachother. I don't want the client to
do the copying from the off screen storage to the screen - that would be
messy (I believe the clients shouldn't be "trusted" - it's easier to
ensure that the server works correctly than that none of the clients
does stupid things by mistaked).
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.
What I've meant with "directly" is that the server could copy the pixel
data directly from the shared memory off-screen buffer and onto the
screen, as opposed to reading it via the Unix domain sockets, into the
servers receive buffer, and then onto the screen.
I'll try to get time to do some work on it this weekend.
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.
My suggestion is thus to add a GrNewPixmap(), GrNewOffscrenWindow() or
GrNewDrawable() or something to indicate an off screen drawable (any
preferences?) 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...
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.
Regards,
Vidar
--
Get your firstname@lastname email for FREE at http://NamePlanet.com
