mac and pc sucks!!!!

[Karlos]

This redraw argument is total b*llocks.

I have 2 RTG equipped 68040 amigas. Both machines have a visible redraw of the background whenever a layer is closed. Whilst it is true that only the area that was obscured is redrawn, the fact is that it is highly conspicuous. The only time you don't notice it is if you have the default "colour index zero" as your background.

[Karlos]

i don't have my CV64 68060 A4000 to check it up and running, but I don't remember any re-draw delays.  At least AmigaOS doesn't feel the need to re-draw every icon on the desktop just for the hell of it.

Well, on both my 8MB Permedia2/CGX 4 and 32MB Voodoo3000/P96 I see it in OS3.1, 3.5 and 3.9. I think I even noticed it in OS4.0 on the Permedia, though it was less conspicuous.

Just stick a nice workbench background image, open a few windows, move them, resize them, close them. I even notice it when using a fill colour (in wbpattern prefs) other than the default grey.

If you don't get a similar visible redraw, let me know what your settings are and I'll try them. The smart/simple refresh only seems to apply to window contents (GUI gadgets) on my machines.

[Karlos]

@Karlos

I just noticed the redraw in AmigaOS on one of my machines, I guess I had been ignoring it until you mentioned it!  Funny how one's mind adjusts to things...

Once you've used a compositing GUI, the old "redraw on expose" methods suddenly look a bit dated. This applies to most user systems, not just OS3.x.

[Karlos]

Right. How about indexing that as you go along, storing that in 500 byte file at the last shutdown, and all being ready to go when you next boot up,taking a microsecond to load at the next boot? And for all the Win 7 talk, XP is still by far the most used OS on the planet. Try launching from the start menu in a fully populated PC and see how long XP takes to draw its menus and icons

Really, do you honestly think the delay when you first access the start menu is caused by having to search a directory tree to see what to populate the menu with? I don't really think that's the killer. Somehow I suspect that physically loading all the icon images and producing their scaled versions for the menu takes longer than that. Then it's all cached for the remainder of your session.

[Karlos]

It's 24 bits per pixel, which is 3 bytes. This means it's 1024x768x3 and 4096x3072x3.

Most 24-bit displays are actually 32-bit, since 3 byte alignment is the devil's work. When an 24-bit image is loaded for display purposes it is often converted to a 32-bit representation in which one byte (normally used for alpha channel) is ignored.

Packed pixel modes, where 3 bytes are used to represent a pixel on screen are generally the preserve of old display cards.

[Karlos]

Hey, don't knock lolcode :lol:

[Karlos]

On a serious note, regarding the "slow" speed of UI response, I think stefcep2 has totally overlooked the important point that a lot of it is deliberate.

He might want menus and the like to instantly flicker in and out of view as he's skimming his mouse through them but most ordinary users are disturbed by it. Consequently, delays are built into a lot of UI systems for the benefit of the end user.

As a worked example, gnome is no different. When you access the menus, there is a delay before each sub menu opens. Is this because the design is "sh*t", badly coded and in desperate need of optimization? No.

If you don't believe me, try editing (or creating if it doesn't already exist) your ~/.gtkrc-2.0 configuration file and changing/adding as appropriate the following:

gtk-menu-popup-delay = 0

Then restart gnome...