nanogui: Hello


Previous by date: 26 Jan 2000 23:02:13 -0000 Hello, daflynn.liberate.com
Next by date: 26 Jan 2000 23:02:13 -0000 Re: Images resolution, Rosimildo daSilva
Previous in thread: 26 Jan 2000 23:02:13 -0000 Hello, daflynn.liberate.com
Next in thread: 26 Jan 2000 23:02:13 -0000 hello, 7811hmx

Subject: RE: Hello
From: Greg Haerr ####@####.####
Date: 26 Jan 2000 23:02:13 -0000
Message-Id: <C1962B36D9BBD311B0F80060083DFEFB041AF0@SYS.CenSoft.COM>

:     It was good talking to you by phone.  I've subscribed and I'll now
: be participating on the mailing list.

David - 
	Yes, it was very interesting discussing modifications that
could be made to Microwindows that would allow the framebuffer
to be mapped directly into the client process's address space,
and using shared code libraries to allow the client to execute the
draw code without having to pass any bitmap or drawing information
down the socket.

Of course, with such a design, it would be possible for an application
to draw all over the screen, but if they used the API, it wouldn't
ever happen.  As a security issue alone, any application could
just open the framebuffer device and draw all over anyway.

There's been considerable discussion on this list about keeping the
size of the image data down on the socket, but we hadn't considered
allowing the framebuffer to be mapped directly into each application's
address space.

I'll be thinking a little more about how we could do this.  The 
next step is separating the window management code from
the drawing management code in each of the respective APIs.
In addition, the current version could be moved to start utilizing
shared libraries.

Regards,

Greg


Previous by date: 26 Jan 2000 23:02:13 -0000 Hello, daflynn.liberate.com
Next by date: 26 Jan 2000 23:02:13 -0000 Re: Images resolution, Rosimildo daSilva
Previous in thread: 26 Jan 2000 23:02:13 -0000 Hello, daflynn.liberate.com
Next in thread: 26 Jan 2000 23:02:13 -0000 hello, 7811hmx


Powered by ezmlm-browse 0.20.