nanogui: Thread: Shared memory + SDL

Hi,

Have any of you looked any at adding shared memory support for the off screen
support?

We have a guy working on porting the open source flash viewer, and it
sort of works. However it would be *much* faster if we could allocate a
chunk of memory for an off screen buffer, and tell Nano-X to add an 
off-screen screen device structure with the shared memory segment as the
frame buffer, and could blit between them.

I'm also considering porting SDL (Simple Directmedia Layer, used by
Lokisoft for Civilization CTP and other games, etc.) to Nano-X in my spare
time, and while it is trivial to do it with GrArea(), it will be a lot faster
with shared memory support (SDL basically keeps an off screen buffer, and has
a call to blit all or parts of that buffer onto screen).

If noone is working on shared memory support, I might take a stab at it,
but I'd like some suggestions about what would be the nicest way of doing
it, though.

Vidar Hokstad
####@####.####

(By the way, I've accepted a new position, and from March 1st I won't be
available on my ####@####.#### address, so any mail directed at me
should go to ####@####.#### or ####@####.#### - I will still work
with Nano-X on my spare time, though :)


-- 
Get your firstname@lastname email for FREE at http://NamePlanet.com

:Have any of you looked any at adding shared memory support for 
:the off screen
:support?

Currently, Nano-X doesn't support offscreen drawing, let alone
offscreen shared memory drawing.  Getting the off-screen
drawing done has been on my list for awhile.  Making the offscreen
buffer sharable would not be that big a deal if the initial call to 
get the memory allocated was passed a SHARE_PROCESS
flag or the like.


Regards,

Greg:

On Tue, 22 Feb 2000 11:56:35 -0500 Kyle Harris ####@####.#### wrote:
>
>
####@####.#### wrote:
>> 
>> Hi,
>> 
>> Have any of you looked any at adding shared memory support for the off screen
>> support?
>> 
>> We have a guy working on porting the open source flash viewer, and it
>> sort of works. However it would be *much* faster if we could allocate a
>> chunk of memory for an off screen buffer, and tell Nano-X to add an
>> off-screen screen device structure with the shared memory segment as the
>> frame buffer, and could blit between them.
>> 
>
>How does shared memory make this faster? What is the flash viewer? Does
>any of this apply to streaming video or short animated clips? 

It applies to anything that maintains an off screen buffer. With shared
memory support, you can just blit the buffer directly onto screen, without
it, you'll end up calling GrArea(), which will serialize the data over 
a Unix domain socket, and the Nano-X server will buffer it in a server
side memory area, and then copy it onto screen.

So you avoid quite a few context switches, and some copies.

Note that this only apply when you compile Nano-X as client-server. When
you link apps directly into the server it won't make a difference.

Vidar Hokstad


-- 
Get your firstname@lastname email for FREE at http://NamePlanet.com

:
:It applies to anything that maintains an off screen buffer. With shared
:memory support, you can just blit the buffer directly onto 
:screen, without
:it, you'll end up calling GrArea(), which will serialize the data over 
:a Unix domain socket, and the Nano-X server will buffer it in a server
:side memory area, and then copy it onto screen.
:

No - this will only work if the application has unobstructed
access (that is, no overlapping windows) on the screen.
Otherwise, the server clip information has to be available
also.  Now, this latter design is one I'm interested in,
but considerably more complicated than Vidar is 
suggesting/requiring.

Greg



:So you avoid quite a few context switches, and some copies.
:
:Note that this only apply when you compile Nano-X as 
:client-server. When
:you link apps directly into the server it won't make a difference.
:
:Vidar Hokstad
:
:
:-- 
:Get your firstname@lastname email for FREE at http://NamePlanet.com
:
:---------------------------------------------------------------------
:To unsubscribe, e-mail: ####@####.####
:For additional commands, e-mail: ####@####.####
:
:

On Wed, 23 Feb 2000 16:42:59 -0700 Greg Haerr ####@####.#### wrote:
>:
>:It applies to anything that maintains an off screen buffer. With shared
>:memory support, you can just blit the buffer directly onto 
>:screen, without
>:it, you'll end up calling GrArea(), which will serialize the data over 
>:a Unix domain socket, and the Nano-X server will buffer it in a server
>:side memory area, and then copy it onto screen.
>:
>
>No - this will only work if the application has unobstructed
>access (that is, no overlapping windows) on the screen.

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.

Vidar.


-- 
Get your firstname@lastname email for FREE at http://NamePlanet.com

: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.

Greg

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

: 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