Re: [MiNT] Re[2]: GEM boost

[Evan Langlois <Evan@CoolRunningConcepts.com>]

Ingo,

Its all about tradeoffs.  As many people have mentioned to me before,
that certain features I'd like to see just won't work on the hardware
Atari users have right now.

On Sat, 2005-07-16 at 00:29 +0200, Ingo Schmidt wrote:
> I will never understand, why eg. Konqueror needs 3-5s to open a
> window. Or Firefox ages to start. OpenOffice 30secs or so.

Because of the amount of configurable options there are a large number
of calls required to perform relatively simple operations.  The
simplicity of GEM may seem like a burden to programmers, but once you
start to really look at how much work is required for the supposedly
"advanced" operating systems, the drawbacks nullify the benefits and
require faster hardware.

Further, large numbers of high detailed, high color icons that have to
be loaded for window controls, toolbars, etc, and layers and layers of
libraries intended to make the programmers job easier, but have been
generalized to the point of inefficiency.  Each library layer also
brings its own unshareable data pages that cause application bloat since
its rare that an application will use more than a handful of what the
library provides.

Also consider that on a virtual memory based system, most of your RAM is
not available.  Program load times are intense since the memory for the
new code and data must be made available, which may require some
swapping, and then the libraries are loaded, and then linked during run
time.  Prelinking libraries will also help quite a bit, and not every
distribution supports this.  Make a linux system with all static
libraries, and it will be much faster, but then you have the situation
where you can't upgrade a library without recompiling all your apps,
like with MiNT now.  And honestly, incompatibilities with library
versions in a dynamically linked system may require an application to be
recompiled and linked anyway, so the benefit dies quickly.

> Or on Windows, the Explorer window, also dead slow. Opening a folder
> with 200 folders inside:
> 1-2s in XP on a 2800XP+ Athlon!

Each file must be tested, and on many systems this means determining the
file type by looking at the file itself and not just an extension, which
means opening all those files.  Then if icon arrangement can be saved,
it has to be restored.  If graphics images are thumbnails, those images
have to be loaded and resized to the icon size.  Image caching and stuff
helps, but then you are loading image caches from disk which is a good
deal slower than just selecting a preloaded icon from your RSC file.

> Ok, havent really tried a Mac yet. Maybe that one can do it...

OS X is nice and efficient.  Its a good design, and most of the graphics
work is done by the GPU, not the CPU, leaving the CPU free to do other
things.  Still, we're not talking about 32Mhz or even 500Mhz machines,
but machines with dual 2 Ghz G5 processors and 500Mhz or so graphics
processors with dedicated memory.  So yeah, it looks and works great
providing you have enough hardware to throw at it and about 256MB of RAM
at the minimum.  Longhorn (next Windows version) will have similar or
greater requirements.

So - many of the features people want, are exactly what is causing this
huge performance difference, but if any group of people can find the
"sweet-spot" happy-medium that gives the benefits of both, I think its
this group here.