|
From: Jeff W. <jw...@ne...> - 2005-12-02 02:38:11
|
On Saturday 26 November 2005 15:07, Daniel Raffler wrote: > Hello Manuel > > > The monitor is obviously a resource consisting of an array of pixels. It > > can be divided and parts (or all) of it can be granted to application > > programs - this ist most commonly done with rectangular regions of the > > screen, known as windows. But of course there could also be circular > > regions or whatever, so nobody limits us to using ordinary windows. > > Supporting non-recangular windows directly in the driver sounds like a good > idea to me, especially as such windows get more and more common these days. > The only thing I'm a bit concerned about is performance as a few extra > copies > will be neccessary to redraw the screen. Using the hardware blitter code > from > the 2D linux drivers this however shouldn't be too big a problem.. Certainly more then one blitting algorithm would be used. It's simply not efficient enough to use a non-rectangular renderer for all windows, rectangular or not. As far as shaped windows, there are two main approaches that I've seen. 1. "alpha" bitmap. In this case, the window is still a rectangle (the smallest rectangle that will encompase the entire window shape) with a coresponding bitmap which controls which pixels are visible or not. 2. span-buffers. In this case, for each horizontal line, there's a linked-list of visible spans. I like the latter option as it can be quite fast when combined with window back-buffers. It also interfaces fairly well with the basic rendering routines if span-buffers are used to calculate overlaps (although I usually use a list of visible rectangles). Span-buffers dont' tend to work very well with lots of on/off detail, however. In any event, as Stephen mentioned, this isn't stuff that belongs in a kernel. This is all part of a windowing system which is one of the final steps in osdev, imo. --Jeff |