OSDev.org

http://trackze.ro/wsbe-5-be-clipped/

This week: Finishing up our rudimentary graphics clipping implementation by updating the drawing methods of our graphics context class to actually be affected by the clipping regions we've set up. Finally, to wrap it all up, we use those updated graphics functions along with our functions for adding and subtracting rectangular regions from the clipping area to draw only the visible portions of our windows, thereby completing the original goal of drawing our windows without wasted pixels.

As a bonus, we also spruce up our window painting method so that things start looking just a liiiitle bit more like we're actually working on a windowing system.

Thanks for the tutorials. I haven't delved into graphics mode yet (I can enable it, just working on other functionality) - but once I do, I'm gonna come back and re-read all of your stuff. Really nice work.

People are probably getting nauseous at me saying it, but, really, I appreciate it.

Even in this misfit community I feel the fear of people telling me my work is stupid (because in many, many ways it is and I'm very much aware of those reasons), and it's been really refreshing that, at the very least, people have so far been abiding by "if you don't have anything nice to say, don't say it at all".

Frankly, I'm surprised at the relatively warm welcome all around to such a weird series. The last three managed to make their way to the middle of the front page of /r/programming, so they can't be that bad.

Can't wait for you to start hacking at it and telling me everything that I could improve!

I'm curious where this is going

I used to work on the Window Server at Symbian back when it existed.

A conventional display graph is usually a normal tree where windows have four pointers: parent, first child, prev_sibling and next_sibling. These are usually stored intrusively in the nodes rather as separate lists.

I will be curious how the drawing is actually done. Early Windows and early Symbian would work out the region (a region being a list of rects) that needs repainting when a window moves, for example, and then for each window it send a 'repaint this region' to the appropriate client. The client would then send the draw commands back over IPC to the Window Server.

Later, we moved to a 'retained mode'. The Window Server would buffer the draw commands needed to paint a window. This made redraws much much much faster.

Retained mode worked much better with transparency too - a semi-transparent foreground window could be seamlessly dragged over the scene without flickering induced by the IPC round-trip time of getting the client to redraw the scene.

Some windows were bitmapped; the client would draw into a bitmap, and the Window Server would blit it. Eventually we went this route with hardware acceleration too.

Its getting beyond a simple Window Manager but the direction things were taking before Symbian faded was towards artwork-based layout. Zach at Trolltech blogged about this http://zrusin.blogspot.se/2006/08/magic.html and we were working on it secretly http://williamedwardscoder.tumblr.com/p ... sed-layout

I think a modern OS ought use HTML to render the UI. Oh well.

I'm also interested where this is going but IMO it's using the techniques that were smart in the '90s, but that have been superseded for various reasons. Having a "redraw rectangle x/y/w/h into this buffer" is a useful API to have, because it allows you to do both double-buffered redraw scenarios and segmented update scenarios (or a mix), but given non-scarce memory, why not just give every window a permanent buffer (or two) to draw into?

I'd be interested in knowing if there are programmable CRTC's that you can point to a scatter-gather list of data to output on the graphics bus - essentially, for non-transparent windows doing the assembly at frame-transmission rather than ahead of time with more buffers. That way you could make moving windows around to be trivial. Does anybody know if that exists already?

This isn't answering your question, as this is too out-of-date and niche, but anyway:

The high-end pre-iPhone smartphones started to get hardware composition of multiple layers.

Early on the camera viewfinder was composed chromakey over the UI buffer, giving two layers. There was a dedicated low-lower compositor built into the display adapter to do this.

Then they all added support an alpha channel in the UI buffer, mostly to give decent UI controls with shadows etc over the camera viewfinder as cameras on phones became crucial.

Then they added support for another type of opaque background layer for the output of OpenGLES. Previously the screen was either 100% GPU or 100% CPU+camera rendering, but by allowing OpenGLES to be a background layer we could have fancy 'transition effects' and an animated UI.

With time, right around the time the iPhone made us irrelevant, we got as far the high-end platforms was being able to compose the viewfinder and UI layers *with* the GPU. We didn't draw the UI with the GPU, only composed with it, but I'm sure we would have ended up only using the GPU for all client drawing.

GPUs took a lot of power but if you had them running to transition effects then you wanted to use them for everything for the duration that they were running.

Of course the iPhone combined a capacitive screen with very very simple 'swish' transition effects that didn't require any heavy lifting, so battery life was actually quite good on the iPhone considering...

It took me quite a while to find some free time and write this review. As always, this is one really informative tutorial, learned a lot from it. After I completed "Get Clippy" I screwed up the entire window manager... I was only able to draw my desktop and nothing else, after some bug-haunting I decided to quit. So I started writing my own window manager. Some images in here. Clipping was a bit too "expensive" and time consuming for me to work on. That end result really amazed me (windows that have title bars and borders). Hell of a good job. I will still keep following you as I go. Every next tutorial = more knowledge for me.

You already have to clip to the bounding rectangle of the window or bitmap that you are drawing to, so clipping to a series of multiple rectangles isn't such as big step up. Often, regions are specified by a list of sorted Y-spans which are then divided into sorted X-spans. It is then easy to compute the intersection, union or difference between regions. Make sure that you have unit tests for these functions.

@Candy: Many graphics cards allow you to set up one or more rectangular overlays which can have their own color format and are automatically scaled. However, the number of such overlays is limited. This is useful for videos and games with rapidly changing content.