Overlapped Windows (GUI)

[djsilence]

Hi, everyone...

I've been thinking for a long period of time about creating overlapped windows. But really all of my ideas was not ideal, so they cannot be used....

Have anybode own once? Or maybe there is a link?

Daniel.

[Firestryke31]

Your not being too clear on what exactly it is you're looking for. Do you want to know how to do it? One way is to have a list sorted by the window "draw order" and draw back to front (slow but easy) or front to back (or even randomly) with a "depth buffer" to keep from drawing the same pixel twice (faster since you don't draw every pixel, just the ones that need it). I personally would go with the depth buffer in case you ever get to the point of supporting 3D since it would require few changes (the card draws everything instead of you).

If that's not what you're looking for then please be more clear...

[Tomaka17]

Do you want to know how to do it? One way is to have a list sorted by the window "draw order" and draw back to front (slow but easy) or front to back (or even randomly) with a "depth buffer" to keep from drawing the same pixel twice (faster since you don't draw every pixel, just the ones that need it)

Personally I'm storing the content of each window in a buffer
Furthermore each window has a flag about whether or not to be redrawn on next render

On render, I draw the root window (if its flag is set), then all its children (if their flag is set), then all its childen's children (same), etc. going from bottom to top
As drawing is a simple memcpy, it's quite fast for something not using 2D acceleration (I remember using XP without any video driver installed, and the speed was about the same)
By the way the "rep movsb" opcode seems to be optimized by Bochs (it goes ten times faster than using a normal loop for copying)

The advantage is that each window's internal buffer almost never needs to be modified (you need so only when resizing a window or when changing the display's color depth, or on some special cases like updating time for the time window)
I'm still thinking about further optimizations, like using buffers with all the window's children drawn onto it


The depth buffer method would maybe go a bit faster, but you couldn't use 2D acceleration (which seems much easier to implement than 3D acceleration)

Of course with my method you won't be able to do things like aero (vista's windowing manager), but this is not my primary consideration

[Firestryke31]

If you do all of your actual compositing offscreen in a buffer, you could still in a way use 2D acceleration to update the screen, and it may be a bit faster since accessing main mem is usually faster than accessing video mem. Plus you don't watch each window get drawn to screen. You'd basically be doing whatever you're doing now except instead of drawing directly to the screen you're drawing to the buffer in main mem, then uploading that to the video mem. The biggest downside is that it takes an extra width*height*(bitdepth/8) bytes of mem.

The advantage to the method you have right now (back to front) is that drawing with alpha will actually work right once you get around to it. As soon as you add drawing with alpha you're pretty much forced to draw back to front due to the way the math works.

[djsilence]

I thout about creating such buffer in main mem as "Virtual Desktop". Everything worked great (I mean minds), but I've got such problem:

For example I have window 1 with client rect 50,50,500,500
Then I create window with client rect 150,150,600,600 - it is an example of overlapped windows.

See, I think about creating such buffer as my VBE framebuffer in size, where every dword would not be a color - it should be handle to my window.

So I should get the picture like this:

0000000000000000000000000000...
0001111111111100000000000000...
0001111112222222220000000000...
0001111112222222220000000000...
0001111112222222220033300000...
0000000002222222220033300000...
0000000000000000000000000000...
................................................

0 - desktop, 1 - window 1, 2 - window 2, 3 - window3 and so on... It is great idea when I need to create mouse support (I have to send message about moving mouse just to that window that is most top and mouse points in that irea. See: I get known from Mouse IRQ what is cursor position, then just get known what is window handler and according to it x and y and that send message... But if I'll move for example window 2 something right... Then to cells when now is '2' I need to put '1'. But not to all (There is cell where I need to put '0'.). This example is trully easy, but its to hard to improve in life... (So what will I do when I'll got 1000 windows???). So I left this idea....

Talking about list of windows order to be drawn - I thought about it. I think it is easy, but not useful (espessialy for future) and not trully fast way.

Sorry for my misstakes in English (I'm very hurry).

So, thanks, Daniel.

[Firestryke31]

Have you considered using rectangles? Something simple like {topLeft.x, topLeft.y, botRight.x, botRight.y} and then to see if the mouse is in the window just to a simple point/rectangle collision detection (see if mousePoint < topLeft && < botRight). Just do the comparisons in top->bottom order and the first hit should be the actual window. If you're smart, you can also apply the algorithm inside the window for buttons and whatnot just by doing some simple math beforehand (and can do it recursively by just doing the same operations for each level you need to, i.e. a button inside a panel inside a child frame inside a window). You could also probably figure out how to use those rectangles to see what really does need to be drawn and do the top->bottom drawing order. IIRC it's what Windows did for drawing before Aero and 3D accel.

[djsilence]

Hmmm... All right...

Thanks, Firestryke31!