[coyotos-dev] Window systems and graphics
devbox at selnet.org
Fri Aug 22 15:05:35 CDT 2008
On 22/08/2008, at 15.27, Christopher Nelson wrote:
>> Let me back up the beginning. One of the principles of Coyotos is
>> storage accountability. A second is explicit destruction: if you are
>> paying for the storage, you can forcibly deallocate it. When these are
>> taken together with the absence of "notify on last close", we end up in
>> a fairly nasty design quandry, in which all of the following statements
>> appear to be true:
>This is probably a serious problem, but not for general graphics
>drawing. Let me explain why:
>In the olden days of vga and ega we just had display memory. People
>wrote into the display memory, and voila! We had pictures. Modern
>graphics architectures still allow that sort of activity, but if you
>do things that way, all you did was buy some really expensive memory.
>The way this works in practice involves translating vector commands
>(DrawLine, DrawRect) into the binary equivalent for the card in
>question. In general, the driver allocates a piece of memory that is
>used as a display list. That memory does *not* specifically refer to
>commands from any particular window or thread or process. It's just a
>When the driver goes to render, it parses the display list, writing
>the equivalent commands into the buffer, just like converting assembly
>to machine code in many respects. Once the display list is complete,
>you program a command register with the base of the display list. The
>video card reads the instructions and performs the necessary drawing.
>Some schemes allow the card to notify you when it is done. Some cards
>can have multiple command buffers active simultaneously.
>In any case, the client doesn't write to the command buffers. It has
>no idea how to do that, or what it should stick in there if it did.
>The driver cares for and owns all memory associated with command
>buffers. Rasterization directly to the display memory doesn't need to
>be (and often isn't) permitted. There is no DoS here b/c the command
>buffers are generally fixed in size and location when the drivers
>The two most common schemes for this implementation w/r to windows
>systems are display lists and invalidation areas.
>With display lists, either the driver or the rendered keeps a record
>of the commands used to draw some area. When the area needs redrawn,
>the display list is replayed. If the client owns the display list,
>then the display server doesn't care about it. It just cares about
>the commands getting replayed to it. If the display server owns the
>commands, I can see how an extremely long play list could be a
Sam: the rendering commands are valid to render *one* single frame, at a
minimum of 25 frames per second. Each frame must be rendered in less than
1/25 of second. So the list of commands is always limited.
>For invalidation areas, no one has a problem. The client is just told
>to redraw a particular region. No extra storage is needed on the
>server side. (This can be implemented with client side display lists
>The other thing to think about involves video processing, and this is
>where you are likely to have real problems. One difference with vector
>rasterization is that the client process needs to hand off video data
>buffers to the driver, or else they must share a circular buffer that
>provides notification to the client w/r to processing lead time.
>This is the same problem you have for sound rendering, though. In
>both cases, the client program really is a client. It responds to
>notifications from the server to update the rendering buffer at some
>location with so much data. However, since active and very low
>latency communication is involved, perhaps this would be an
>appropriate place for watchdog timers.
>coyotos-dev mailing list
>coyotos-dev at smtp.coyotos.org
More information about the coyotos-dev