Windows GUI technology

[interr]

Hi, it's logical that non-buffered forms uses for each component an event called like 'component_redraw', which been called on form moving, on form repairing, etc.
BUT I have found that MS Windows hasn't 'component_redraw' I described.
Some people say: MS Windows forms are non-buffered.
So does MS Windows use buffered windows? Your args are welcome.

[Tim]

You're right, by default Windows' windows aren't buffered. As of Windows 2000 you can get Windows to store a bitmap representing your window, but this is to support layered windows (windows with an alpha channel); you should use the normal WM_PAINT mechanism for everything else. WM_PAINT sounds like the equivalent to what you call component_redraw.

The reason for this is that it would be just too expensive to keep a copy of every window's image. Also consider Windows' original target platform (an 8086-based XT with 256KB memory and an MDA video card); nobody would have considered for a moment buffering windows back then.

[Brian_Provinciano]

Individual window buffers would generally be a memory hog, especially when you think about the fact that most windows simply contain an array of controls/child windows, all standard windows controls. It takes milliseconds to redraw them all. Using a WM_PAINT to draw a buffer to the Window is quite efficient. Automatic Window buffers could be less efficient. If they automatically repaint the updated pixels on each write, that would slow things down. On the other hand, if they didn't, you would need to do an InvalidateRect() type thing to update the new buffer. If that'd be the case, you may as well just replace that call with a DrawBuffer()+InvalidateRect() combo.

[Pype.Clicker]

the approach i plan to follow mixes both buffer and redraw, in a way. I'd like to have a buffer of the 'redraw' commands, so that the server is able to repaint things itself, and notify the client of high-level events like "Ok button pressed on Save Document Form: save format=png, filename=girlfriend.png" rather than all the individual small events.

something looking like a limited virtual machine should provide the flexibility required to offer this even on newly created widgets ...

[mystran]

Actually, www.freedesktop.org is developing an extension to X that does buffering of all windows to allow alpha-channels and window shadows and such.

The memory issue actually isn't that bad anymore. Many video cards have enough memory to put most of your windows directly into the video-memory.

[Pype.Clicker]

The memory issue actually isn't that bad anymore. Many video cards have enough memory to put most of your windows directly into the video-memory.

Provided that you know how to access that extended video memory efficiently, which is not yet my case ...

[Solar]

You remember AmigaOS? The thingy that ran in 1 MByte RAM and had a GUI responsive as hell?

Well, they did buffer their windows...

[Pype.Clicker]

You remember AmigaOS? The thingy that ran in 1 MByte RAM and had a GUI responsive as hell?

Well, they did buffer their windows...

But they also had a graphic chip that could be programmed with copperlists like
"when offset-on-line=12 pixels, draw from video memory 0x1234 ; when offset-on-line=212 pixels, draw from video memory 0x5678;
when line done, load new copper-list from main ram at 0x0100;" etc, hadn't it ?

[neowert]

Is there any advantage to buffered mode? Aside from the extra effects n stuff? It would seem that redraw would be faster, as only certain parts need to be redrawn.

[Solar]

But they also had a graphic chip that could be programmed with copperlists like
"when offset-on-line=12 pixels, draw from video memory 0x1234 ; when offset-on-line=212 pixels, draw from video memory 0x5678;
when line done, load new copper-list from main ram at 0x0100;" etc, hadn't it ?

What you are referring to is the "Copper". While being a nice piece of hardware allowing nifty tricks (like a 512-color gradient background on a 4-color screen ), it was not involved in windowing matters AFAIK.

You probably refer to the "Blitter", which was responsible for making block transfers in memory. Yes, that one allowed early Amigas to be quicker in GUI related tasks.

However, from the MC68030 CPU upwards, most people employed a hack-patch called "FastBlit" that disabled the Blitter because the CPU was faster at the task...

[Solar]

Is there any advantage to buffered mode? Aside from the extra effects n stuff? It would seem that redraw would be faster, as only certain parts need to be redrawn.

With buffered windows, the GUI subsystem can handle the redraw "in-house". While an application is not scheduled, its window contents aren't likely t change anyway.

Without buffering, you have to message the application, schedule the application (context switch), having the application do a partial redraw (with the extra logic involved - what to redraw, what not to), including some tricky memory mapping (so a rampant application doesn't draw into other application's window space), then switch back to the GUI subsystem (message, context switch).

I think unbuffered windowing is the reason for most of the "desktop garbage" you experience when putting a Windows system under load.

[Pype.Clicker]

my personnal suggestion is that the GUI server could buffer the description of what is to be redrawn, rather than the result of the drawing.

That's the root idea of my future-yet-to-sketch Y-windows server ...

[Solar]

Are you sure that's the right layer to do the abstraction? I pictured the description-to-bitmap renderer to be above the bitmap-to-display component, so it could be replaced e.g. by a description-to-3D renderer, or description-to-audio or else...

[Tim]

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.

Certainly I don't think it makes any sense to optimise drawing by removing extra context and address space switches -- 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.

[darklife]

my personnal suggestion is that the GUI server could buffer the description of what is to be redrawn, rather than the result of the drawing.

That's the root idea of my future-yet-to-sketch Y-windows server ...

GREAT IDEA! Why didn't I think of this sooner?