Colouring lessons page 6
This screenshots gallery generally relates to screenshots of graphical interfaces. The fundamental nature of a graphical interface is colouring in the screen with lots of pretty pixels. And for some reason, we still cannot seem to even get that much to work reliably…
I have already said more than enough about the Windows window mangler, but even EIKON – Psion’s window server – has its off days. When you open a control panel in EPOC, the controls seem to get drawn before the window does:
OK, I cheated, although the discovery was purely accidental. Select a control panel and press enter twice in rapid succession; the keyboard is being monitored even before the window is done being drawn. You will be treated to the OK button (in its pressed state) and one control label being drawn in without the rest of the window.
A stranger flaw is to be found in the EPOC shell, which commonly fails to draw in its window properly:
Ah, GraphicConverter, packed with an equivalent (and sky high) number of both features and bugs. Here, reverting a crop of an image drew back something completely random instead of the rest of the image:
Now, the Google Earth Web site does tell you somewhere what video hardware it supports, but try explaining that to a technophobe user of an iMac who has no idea what to do with system profiling. Supposing you run the program, you’d expect a polite reminder that the video card in your iMac is inadequate, but instead you get something like this:
The real irony is that the hardest part of all, the three-dimensional Earth, is drawn just fine. I am not sure why slapping a bit of text over the top fails so spectacularly.
One of the strangest bugs I have seen so far, is in MBMView. If you open an image with its main toolbar hidden:
And then display the toolbar:
It draws part of the image back over itself, including making the assumption that white pixels are transparent. Very bizarre.
I don’t know what happened in the following screenshot, except that a Flash movie failed to redraw. It might be something to do with Windows’s painful redraw method:
Of course, Mac OS has bizarre problems with window redraw too. For example, if a dialog box pops up in the background, it will draw in a disabled style. But when you activate the application and covered-over parts of the dialog redraw, only those redrawn parts take on an active style:
With the curious exception of the button, which is drawn active even when the window is inactive.
I forget whether the following flaw is also present in the XP version of Internet Explorer 6, but in the Windows 2000 version, using the mousewheel to scroll an image shown at full size has problems:
This next one, I’ve had stashed up for a while now. I right-clicked on a taskbar button instead of the taskbar itself by mistake, and then moved the cursor over the blank taskbar area and clicked again:
Yep, it forgot to redraw where the old menu was. I imagine I was playing Solitaire because the company database was up the creek once again: I have never seen any other software in my life routinely take 10-20 minutes to load.
Finally, an old bug in Windows QuickTime (version 6 here) – when playing a movie, and you return to QuickTime’s window, it sometimes leaves the old playback position marker behind when drawing in a new one:
