Windows GUI technology

[Solar]

having the application blt the window to the screen is so close to the speed of having the window manager blt that the user won't notice.

Not the user, but the rest of the system...?!?

[Tim]

To the rest of the system, the overhead is as bad as any other context switch. I'd guess context switches will happen more often for other reasons -- file I/O finishing, mouse movements, key presses -- so the extra overhead for window repainting will not matter.

[Solar]

Hm. Doesn't every mouse move require some repainting due to the movement of the pointer?

It's your design, but I consider "good enough" to be a bad reason for a design decision. IMHO only.

[BI lazy]

@solar:

The video driver is in the sole responsasbility for the mouse - at least in my system. So it is also responsible for drawing and moving the mouse over the screen - in videomemory. the mouse pointer is the only thing I don't buffer at the moment. It draws quick and is synchronized with vertical refresh. Why in the video driver: Ha, imagine all the funky mouse movement messages being sent to the gui service - its slooooow like hell. So, I've implemented the mouse driver lik the keyboard driver: a variable is set to 1, the timer isr checks this var and wakes up the video task to check the according input queues for events. This system is hmm ... kind of a hack, but it rocks like elviz the pelviz )

[Pype.Clicker]

I believe painting in an application can be as fast as painting by the GUI.

Why? Because the user can't see anything that appears on screen more quickly than the refresh rate of the monitor. Anything that can be drawn more often than 60-100Hz smooth enough. Drawing any faster than that is pointless, from a UI point of view.

That's a wise remark. however, i tend to use a lot of programs over internet connections (ssh -X ... you know what i mean). With all those newer apps that try to have a 60fps "download in progress" animated icons, buttons that have hover behaviours, etc. it's really a pain ...
I figured out that if you had the ability to send

Code: Select all

(animated-button 
   content: ((box bgcolor=darkgrey #stacked) (text "ok"))
   on GUI.hover: (
        target_color=lightgrey;
        enable GUI.retrace;
   )
   on GUI.hout: (
        target_color=darkgrey;
        enable GUI.retrace;
    )
    on GUI.retrace: (
        if (box.bgcolor == target_color) disable GUI.retrace;
        if (box.bgcolor < target_color) box.bgcolor++;
        else box.bgcolor--;
    )
)
[/quote]
we could have more efficient and still customizable GUIs.

[interr]

What about forms inviolability? - I mean forms with actives components shouldn't damage other forms.
Let's say a GUI doesn't use any buffer.
The simplest way to avoid the damage is to check each component pixels. If pixels collision with other forms, they won't put in video memory. Actually this way is very slow.
Have any ideas or faster methods?

[Pype.Clicker]

What about forms inviolability? - I mean forms with actives components shouldn't damage other forms.
Let's say a GUI doesn't use any buffer.
The simplest way to avoid the damage is to check each component pixels. If pixels collision with other forms, they won't put in video memory. Actually this way is very slow.
Have any ideas or faster methods?

Usually, servers that do not have client-window buffer receive commands like "draw line x1,y1-x2,y2", "fill box x1,y1,width,height", etc. The server then clips the coordinates according to the current windows's area and translates the commands into "safe" commands that do not get out of the region. Then it draws the result of "safe" commands.

[Tim]

A better way is to keep track of a clipping region for each window. A clipping region is an array of rectangles.

To construct a clipping region:
1. Add a rectangle for the whole window
2. Subtract the rectangles for all the other windows

Subtracting one rectangle from another is not trivial, and can result in zero, one, two or three rectangles. So the final clipping region can be quite complex. To support non-rectangular regions, replace 'rectangle' in (1) and (2) with 'region', where a region is an array of rectangles.

To draw a clipped shape in a window:
1. For each rectangle in the window's clipping region:
a. Clip the shape to the rectangle
b. If the clipped shape is within the rectangle:
-- Draw the shape

Clipping a rectangles to a region is relatively easy, if you come up with a routine which gives you the intersection between two rectangles. Clipping to horizontal and vertical lines is even easier; and clipping to horizontal lines lets you clip to polygons (given a routine which converts a polygon to a set of scan lines). Clipping lines and more complex shapes is harder, and requires some maths.

[Curufir]

I'm kinda partial to storing vector operating actually. If you maintain a mathematical description of the screen as opposed to a bitmap description then clipping and everything else usually just involves some fairly trivial matrix operations. I guess this is just another form of Pype's idea of storing the description, but in a more formalised manner. I'd even go so far as to think you can seperate things out as individual objects that can themselves contain other objects.

Eg

I draw a line and a triangle inside a box. So I get an object hierarchy that's something like

Window object -> Box object -> Line object : Triangle object

Where an object itself is stored as a vector description.

So if I move the line, the only two things that get sent to screen are the replacement pixels for the deleted line and the pixels for the new line. That way VRAM transfers are kept to an absolute minimum (Although you'd still have to do some calculation on the window scene to figure out the replacement pixels).

Another neat thing is that if I apply the simple rule that "moving an object also moves all objects it contains" windowing becomes very simple conceptually. Likewise buttons with text, controls etc, are all concepts that fit quite naturally in that scheme. In fact there's no reason an object can't have no visible component, so grouping of visible objects in an invisible container is quite possible.

The idea needs a lot of work, but I'm nowhere near implementing a GUI yet so I have plenty of time ;D.

[Tim]

That's all very nice, but how would you store something which actually is a bitmap? Say, for instance, a program which displays a GIF file? Would you encode it as lots of squares, or embed a bitmap in the vector data stream? How about a program which displays a zoomed-in view of some other part of the screen in its window?

[Curufir]

That's all very nice, but how would you store something which actually is a bitmap? Say, for instance, a program which displays a GIF file? Would you encode it as lots of squares, or embed a bitmap in the vector data stream? How about a program which displays a zoomed-in view of some other part of the screen in its window?

By ignoring the fact that it's a bitmap until such times as I need that information.

A bit map can be thought of as just a flat shape filled with pretty colours. The only piece of information relevant to clipping/motion/etc is the shape of the bitmap which usually can be described in vector form. So for all operations that relate a bitmap object to other objects only the shape is used, with the final rendering using the bitmap as a texture clipped to the visible area of the shape.

I suppose what I'm talking about is separating the shape of an object from the contents of the object so that I can use well documented and heavily researched 3d maths for determining what does/doesn't need to be redrawn. The contents themselves are only important when it comes to finally rendering the objects on the screen.

As I mentioned, I haven't laid down any code for my graphics server yet so this is all just the result of my brainstorming. I've no doubt there will be plenty of obstacles to overcome when I get around to implementing it, but I think the idea is sound.