OSDev.org

When a GUI changed active source the screen needs to be refreshed to show it. In my design each task 'window' occupies all of the screen except the menu at the top. This area is 640x440 which means to change the display would require first a 281.6kb save then a 281.6kb read plus the time to switch planes etc. How do real GUIs work? Is it object based (e.g. 'HELLO WORLD!!!' at 100, 50 in colour 4) or what? I know that I can leave the display as it was then tell the VGA not to update the display do the changes and then tell the VGA to go 'on' again which will remove the visual scrolling process, but there would be a period where the OS would appear to have crashed.

Therx

p.s. My site is back up

Observe two things about GUIs:
-- most of the time you don't redraw the whole window
-- the stuff you draw in the window can generally be reconstructed by the program

For instance, look at a web browser. The web browser keeps a parsed copy of the HTML, and all the images, in memory. It doesn't need to keep the entire web page rendered in memory because it can just redraw it when needed. Now imagine scrolling this page. You only need to redraw the part of the page (the top or bottom) that has just been exposed.

If you keep a copy of every window's image in memory then your memory requirements go through the roof (imagine your GUI running at 1600x1200x32). What you should do is provide a way for the GUI to notify a program that part of its window needs to be painted, and have the program repaint it in whatever way it sees fit.

Thanks Tim. That's what I'd thought. But what I'm still not sure is whether the GUI engine or the app should store the info. if the app stores it then I need to implement IPC before I realy want too.

Client/server X-window system has an interresting intermediate approach: some resources like character fonts and so-called pixmaps (pixels maps : buffered images) are kept on the server while the application structure is kept on the client. So when a browser page has been exposed and need a repaint, the "EXPOSED" event is sent to the client (the browser), which determines the operations to be performed (like "draw a grey square (x1,y1,x2,y2) - draw text "blahblah" at x3,y3 using font in resource 0x12345678, then draw (x,y,w,h) out of pixmap 0x87654321 at (x4,y4)".

This reduces the need for transmitting the information, and help putting pixmaps, etc. in the offscreen video memory when possible (which usually gives better performances on powerful videocards).

The disadvantage is that modern UI have animated buttons, menus, etc. , which require a *lot* of communications and request/replies between X entities -- thus limiting the performances.

That's why i think about extending the "resource" to programmable items so that what the application can send to the graphic server looks more like flash than like a .bmp image.