nanogui: Technical Framebuffer proposal for RTEMS graphics
Subject:
Re: Technical Framebuffer proposal for RTEMS graphics
From:
"Frank W. Miller" ####@####.####
Date:
5 Feb 2000 19:58:00 -0000
Message-Id: <200002051846.NAA06560@macalpine.cornfed.com>
> the read/write functions could be used as pixel set/get functions.
>
Hehe. I was waiting for someone to propose this. I hope you'll pardon
me now, I'm going to start down a monologue based on my dissertation
work. If you're not into windbag academic arguments, just hit `d'
now.
Many moons ago (or about a year anyway) I was working on something called
data streaming through the kernel. The idea was to use a single buffer
representation that was similar to mbufs in all the I/O elements, file
systems, network protocols, and yes the windowing system, so that data
could be passed between these systems easily by reference.
When I got round to thinking about how this would work with the graphics
devices, I started to think about allowing something like this:
ioctl(fb, START_BLIT)
stream(source, fb);
ioctl(fb, END_BLIT)
The idea is to give the graphics system the parameters for the destination
of the blit in the START_BLIT and then feed it zero-copied buffers from
whatever source, a file, a socket, another part of the screen. This would
in theory boost transfer performance dramatically. I did lots of work on
this with file systems and network protocols but never got around to
implementing it for a graphics system.
The main trouble here is the fact that theres no atomicity between the
ioctls and the stream calls. This could make it tricky, I didnt go far
enough down the path to figure it out. Anyway, this is all probably not
really relavent here right now. Some might find it mildly interesting tho
so wtf. For fun, a link to my disseration is at
http://www.cs.umd.edu/~fwmiller/doc/dissertation/dissertation.html.
Later,
FM
--
Frank W. Miller
Cornfed Systems Inc
www.cornfed.com
