The Joel on Software Discussion Group (CLOSED)

A place to discuss Joel on Software. Now closed.

This community works best when people use their real names. Please register for a free account.

Other Groups:
Joel on Software
Business of Software
Design of Software (CLOSED)
.NET Questions (CLOSED)
TechInterview.org
CityDesk
FogBugz
Fog Creek Copilot


The Old Forum


Your hosts:
Albert D. Kallal
Li-Fan Chen
Stephen Jones

Why repaint not done by OS

When I first started doing C++ programming I was surprised to learn that each application was responsible for doing its own repaint. If a window is partially or fully covered by another window then uncovered the operating system does not handle the repaint.

I wonder why Microsoft decided to do it this way. What are the advantages and disadvantages? Are there performance concerns?

How much different would things be if the operating system kept track of what was on each window and repainted newly exposed sections?
XYZZY
Tuesday, May 08, 2007
 
 
I imagine it's because your window might have changed since it was covered up. You don't want Windows repainting the old version.
JW
Tuesday, May 08, 2007
 
 
Say you are a movie player, how should the OS repaint you?

Tuesday, May 08, 2007
 
 
Repaint of what?  You might have a sort of backstore of pixels (which may be huge), some internal data storage thingie, a display list of vector graphics, etc.

FWIW, there was a sort of nudge this direction in hardware for a bit.  I think Intel (the 82786?) built a chip that was intended to do hardware windowing, with each application owning a chunk of bitmap.  The problem is that everyone wants something different.
old.fart
Tuesday, May 08, 2007
 
 
>>"Repaint of what" and "You don't want Windows repainting the old version."

Of course you don't want old data repainted. What I mean is that every application window would have a virtual window that is connected to the OS. Whatever is written into the virtual window would be managed and repainted to the screen by the operating system. This would be much like is done with any VB or C# graphics application. There would be no need for code in every application to repaint sections of the screen, or even necessarily keep a list of things that have been drawn to the screen.
XYZZY
Tuesday, May 08, 2007
 
 
I suspect it's because in the old days when Windows was developed, there wasn't enough RAM generally available to maintain the image of every window that was obscured or otherwise "offscreen". So when a window that was previously obscured was revealed again, that window's application would be asked to re-render itself (or at least the portion that was newly revealed).

I'm not sure, but I think Vista uses a different paradigm...?
Jesse Send private email
Tuesday, May 08, 2007
 
 
> Whatever is written into the virtual window would be managed and repainted to the screen by the operating system.

That would take memory and CPU (to paint hidden windows).

Anyway, I think that perhaps Vista might have somehow implemented the change you suggest.
Christopher Wells Send private email
Tuesday, May 08, 2007
 
 
Mac OS X does indeed automatically retain a buffer of each window, and I'm fairly sure that Vista and Linux running compiz/beryl do as well.

As for why it wasn't originally done that way, the simple answer is that it would take far too much memory. Go back 15-20 years to when all the display systems you're used to (X, GDI, QuickDraw) were designed. To store a 640x480 image using eight-bit graphics (256 colors), you need at least 307k of RAM. Add three windows, each 75% of the size of the screen, and try to buffer them in the OS, now you're talking about an additional 690k just for holding images, most of which the user can't even see. In an era where computers had at most 4-8 MB RAM, that's a horrible waste of memory.

If, instead, each window is in charge of repainting itself, then you don't have to spend all that memory retaining bitmaps. Sure, the windows will have to retain some auxillary data so they can repaint themselves, but now we're probably talking about just a handful of 8x8 bitmaps and a kilobyte's worth of vector drawing routines. It's a huge save.

Nowadays, when computers have a couple of gigs of RAM, wasting a couple dozen megabytes on window buffers is a reasonable trade, but the original decision most definitely made sense at the time.
Benjamin Pollack Send private email
Tuesday, May 08, 2007
 
 
Repainting is the old Win32 way of doing it for the historical reasons that Benjamin Pollack described. The new way is Windows Presentation Foundation (WPF, formerly known as Avalon) which will handle repainting for you, see this article, point 9:

http://msdn.microsoft.com/msdnmag/issues/06/01/windowspresentationfoundation
Mellowman
Tuesday, May 08, 2007
 
 
It means that when the window is not visible, it doesn't have to do the repaint. Have you ever noticed that some applications that show a lot of output (scrolling text in particular) run faster if the window isn't visible?
Andrew Rowley Send private email
Tuesday, May 08, 2007
 
 
>> It means that when the window is not visible, it doesn't have to do the repaint.

I'll bet that nearly every application has all the code in place to invalidate the window and repaint even if the window is not visible.  The OS is saving time here by not going to the hardware.  I don't think if the OS managed the repaints the results would change in this regard.
XYZZY
Tuesday, May 08, 2007
 
 
Not painting when a window's not visible and the OS maintaining a buffer are unrelated. On OS X, which is OS-buffered, an application normally calls -[NSView setNeedsDisplay:] or -[NSView setNeedsDisplayInRect:] to invalidate the relevant portion of the window. If the window's hidden, Quartz won't issue the repaint call. The only difference is that if the window is visible, gets covered, does not update, and is then exposed, Quartz blits directly from its cached image of what the window looked like. I'd imagine WPF works the same way, though I haven't had a chance to work with it yet.
Benjamin Pollack Send private email
Tuesday, May 08, 2007
 
 
You don't want the OS keeping a screen buffer. How would you do hardware decoding of video or things like vertex lists if you had to blit the entire screen over to system RAM for the OS every frame, which then would blit it back again to display it? The whole problem with slow graphics was limited bus bandwidth which is why graphics is offloaded to hardware instead of going through the OS.
Bob
Tuesday, May 08, 2007
 
 
Don't forget that the two models are not incompatible.  At any time, MS could have simply had a buffer be the resource that your screen was drawn to and display that.  The existing invalidate procedures would still work, only they would invalidate the buffer instead of the screen, the buffer could still redraw the screen if the app hadn't responded yet.

BTW, anyone wonder how Windows NT 4 implemented "full windows drag"?  We take it for granted nowadays, but back in 1995, windows went white while you were dragging them.  Now, guess why that doesn't happen anymore.  Yup, there is an OS buffer to hold the image of the window while dragging.
JSmith Send private email
Tuesday, May 08, 2007
 
 
"At any time, MS could have simply had a buffer be the resource that your screen was drawn to and display that."

They've always done that ("Display Context" in GDI). The reason they (wisely) decided not to have the OS automatically re-draw your app's graphics for you when your window's been "dirtied" is to give you the option of using the slow OS system RAM screen buffer or go direct to hardware on your own. That lets users take advantage of advances in hardware without having to upgrade the OS. It's also more pragmatic from an OO perspective to have objects ("applications") draw themselves, rather than something else  drawing the object. More options for developers = more innovation = better apps = more market share for MS!
Bob
Tuesday, May 08, 2007
 
 
That's not a buffer, it's an interface.  Sometimes it's buffered, like for full window drag.  Until recently, it was usually not buffered, most GDI calls to screen contexts are converted directly into video driver calls nowadays.  Write a VB 6 app with a nice tight neverending while loop in the code for a button.  The screen will have massive repainting problems, proving that there is no OS buffer.

We're on the same side of this discussion, but your incorrectly rebutting my point is a bit confusing.

My point was that usually, MS leaves you alone to do repainting.  But, they did it in such a way that they can buffer the screen if it makes sense.  They've done it a few times, once for full window drag and now for Aero in Vista.
JSmith Send private email
Tuesday, May 08, 2007
 
 
Well guys is it the same issue that Swing applications running on Window OS have.
Badly coded Swing GUI also has repaint issues but it can be handled well using correct approach.
And yes I guess its better to let the application displaying the window to decide when to repaint.
Hence you can reduce overhead on OS as repaint is an exhaustive task.
kooldudeno1@gmail.com Send private email
Wednesday, May 09, 2007
 
 
the real reason that current windowing systems, by default, don't support 'backing store' (a buffer that stores the image of window so that it can be repainted by the OS/Window server) is that, when the three major windowing systems were developed, back in the mid-eighties, AT&T had a patent (Pat. #4555775) on the technique. In order to avoid paying royalties to AT&T, Apple, MIT and Microsoft all elected to use a redraw mechanisim that didn't keep the image of the window and required the application to redraw the window whenever necessary.

Some systems (classic Mac OS, for example) allowed you to attach a list of drawing instructions (a PICT resource, similar to a Windows Meta File) to a window and the OS would use that to redraw the window. I only used that technique once, for a start-up splash screen that I wanted to have displayed before enough of my program was initialized to respond to events.
Jeffrey Dutky Send private email
Wednesday, May 09, 2007
 
 
If you are referring to MS Windows then the answer is that it can perform the repaint for you. The CS_SAVEBITS window class style instructs Windows to cache the screen area obscured by your window and restore it when the window is moved/hidden/destroyed.

For more information on the advantages and disadvantages of this style and also guidance on when to use it see: http://blogs.msdn.com/oldnewthing/archive/2006/04/28/586018.aspx

BTW programmatically repainting isn't very hard since your application presumably has all the paint know-how anyway. After all, it created the original image. The real question is: "why is painting so hard?". The answer is that GDI from C++ is really low-level. As has been mentioned by others in this thread, the future looks brighter (WPF, etc.)

Dan
shappir Send private email
Wednesday, May 09, 2007
 
 
In Windows Vista with Aero graphics enabled the OS can repaint the window for you when it's exposed.

That's the feature that puts the "WoW!" in Vista - or so I'm told.
Jimmy Jones
Wednesday, May 09, 2007
 
 

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
 
Powered by FogBugz