[coyotos-dev] Window systems and graphics

[Valerio Bellizzomi]

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
>command buffer.
>
>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
>initializes.
>
>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
>problem.

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
>too.)
>
>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.
>
>-={C}=-
>_______________________________________________
>coyotos-dev mailing list
>coyotos-dev at smtp.coyotos.org
>http://www.coyotos.org/mailman/listinfo/coyotos-dev