Page 1 of 1

Windowing help (kinda OS related)...

Posted: Tue Aug 13, 2002 10:52 pm
by Kenneth Garin
Im trying very hard to understand how a modern window manager works. My question is how do I overlap windows and still be able to draw into background windows w/o drawing into the foreground (active) window? I need to do this so that for example a window in the background can be showing a movie while the active window (partly covering background window) is doing something else, like maybe word processing or something.
I need to do this w/o page flipping because the SVGA library im using doesn't support it very well. I can't say what programming language im gonna use to make this because I plan to test it in many compilers and see what works best.
Thanks much, Kg.

Re:Windowing help (kinda OS related)...

Posted: Tue Aug 13, 2002 11:08 pm
by roswell
Hi,

I am not sure about the solution, but here is what I propose.

First , you must create an off-screen drawing area for each window you want to draw on.

On screen update there are two solutions :

-you must copy each buffer into a large single one in the order the windows are stacked on the screen, and at the end copy this large buffer on the screen memory. The screen buffer avoids flip.

- before drawing a point on the screen, you look into the windows stack to see which top window contains this point, and you pick up the point from the corresponding buffer. ( Yoiu can also use double buffer here)

These two solutions are memory consuming, but this is normal I think, you can not have performance without resources.

May be there are others solutions, but I think they are derivated from these two ones.

Roswell

Re:Windowing help (kinda OS related)...

Posted: Wed Aug 14, 2002 1:07 am
by Pype.Clicker
using the paging informations could also be helpful : if you have a big buffer for your background window, having the manager looking at what page have been modified (dirty bit set) since last refresh give you hints on what buffers (and which set of rows) have been changed by the application, and therefore allow you to repaint only those parts.

One of the most complex part of your job will be to define which area of the windows are to be redrawed (i.e. which one are visible), but as this only changes when windows are moved, this information can be cached and reused as long as the windows don't move...

Ok, I think I understand most of it now...

Posted: Wed Aug 14, 2002 1:36 am
by Kenneth Garin
but for example, how does MS-Windows do it? I guess they must use a offscreen buffer also? Heh, so much for using a standard SVGA library.. :(
Kg.

Re:Windowing help (kinda OS related)...

Posted: Wed Aug 14, 2002 2:11 am
by Krom
I'm not an expert on windows, but i know something...

Windows doesnt redraw the windows by itself. It does have buffers for the applications. When one application draws something, it never goes to the screen. It always goes to another place. The application must tell windows it wants to update what it draws. For exaple, You create a window and draw one line, and do nothing more. The line will not be displayed. You must tell windows to update the screen. When you do this it will redraw it. When another windows thats overlaps yours is moved, windows send a message to your application telling you this, and it give you some rectangles that are visible. So you redraw only the parts that are visible. More or less is like that.

One example is a program that reproduce a movie, it must tell windows to update everytime he finish drawing a frame.

I think almost all the people have seen that sometimes in windows some applications doesnt redraw. When you put another window over it or, move, the old window image still is there, looks like it hung up. The reason is because the application is not sending the UPDATE signal to windows, maybe because it is doing another thing and doesnt have time to send it. You can avoid this problem if you make a thread only to redraw, and tell windows to update.

i expect that it helps you.

Re:Ok, I think I understand most of it now...

Posted: Wed Aug 14, 2002 6:18 pm
by Tim
Kenneth Garin wrote:but for example, how does MS-Windows do it? I guess they must use a offscreen buffer also?
Remember that Windows was designed back in the early 1980s, when machines had very little memory, and even less graphics memory. Back then it wasn't possible to create an offscreen buffer for the screen, let alone each window.

Windows handles drawing to overlapped windows by defining clipping lists for each window. A clipping list is a list of rectangles (actually a shaped region object on Windows) which defines which areas an app may overwrite into when it draws into its window. A top-level window's clip list will have one rectangle covering the whole window; a totally obscured window will have an empty clip list. A partially-obscured window will have a clip list with rectangles covering the exposed area.

All the high-level Windows drawing code knows to only draw into the areas permitted by the window's clip list (actually, it's possible to draw on top of other windows, by obtaining a screen DC instead of a window DC). For example, the FillRect function might loop through all the rectangles in the clip list, and, for each one, calculate the intersection between the desired fill rectangle and the clip rectangle. If that intersection is not empty it draws there.

This method turns out to be far more memory-efficient than offscreen buffers (you only have to allocate lists of rectangles instead of bitmaps) although it's a lot less flexible (it's harder to combine windows' contents by e.g. alpha blending). Note that alpha blended windows on Windows 2000 and later use offscreen buffers to draw themselves.

Re:Windowing help (kinda OS related)...

Posted: Thu Aug 15, 2002 6:55 pm
by Kenneth Garin
Thanks everyone! That info on MS-Windows helps me a lot since I want the window manager to be as memory efficient as possible. I have a graphics library im using that supports a command called SETVIEW(x1,y1,x2,y2) so maybe I can use this to clip areas that I don't want to draw on (where other windows overlap).
The bad part is that I will probably have to rewrite a lot of the graphics functions.
Kg.