Cool!!! Well done, Jorge!

Thanks.

Made many changes to the Fx Engine too.

A lot of the new effects have many frames of animation, which means heavier memory consumption when you use them since those bitmaps need to be cached in memory.

Also, since most of those new effects are closed loops of animation (i.e.; no beginning and no end) I felt the need to make some of them smoothly fade in at the beginning and fade out on exit so the animation does not stop (or start) abruptly - the currently available Smoke effect is an example of an effect that needed this feature, it just stopped abruptly as you moused out of the icon - now it smoothly fades out.

But there is always a price to pay! Fading the animations in and out meant processing their alpha channels in real-time, which is pretty CPU intensive. With these last animations being really long (some have more than 30 frames) and needing to complete a full cycle in order to fade out, this meant that, when quickly moving the mouse across a dock suddenly most the icons were in the process of having their effect fading out. That means rendering hundreds of frames per second!

Combine this with the processing power required for the parallel icon magnify effect and things start to really slow down to unacceptable levels, even on my PC's 4.5Ghz CPU.

I solved this by pre-processing the fade out and fade in animation frames the first time the animation runs and caching the result in memory. Unfortunately this can mean up to three times more memory usage for that effect (normal animation bitmap, fading-in animation bitmap and fading-out animation bitmap all cached in memory at the same time).

For instance, a 1536 x 768 pixel RGBA animation sheet with 32 frames uses up to 4,608 KB in memory. With the 3 copies, that's 13,824 KB for a single effect.

However I believe speed is more important than memory usage these days, and since it is also faster to render a bitmap at the original size than it is to scale it down, to further speed things up I also cache animation bitmaps pre-scaled for a specific icon size (in a magnifying dock, only 3 or 4 icons are magnified at a time, all the others have the same size). These pre-scaled copies use less memory than it's bigger 'original' brother (which is ALSO cached in memory) but it all adds up.

Of course, I optimize all this so the different bitmap versions are only cached if strictly necessary, but still... A single animated effect can make a HUGE difference in the memory usage of the application.

Now picture this: the new Effects Panel shows off *all the effects* at the same time. Multiply 10 MB by the number of available animation sheet effects and you can imagine the memory usage of the application while this panel is open lol Of course, all that memory is freed as soon as the panel is closed.

Since some users still pay attention to how much memory a dock uses (even though they think nothing about their web browsers using up to 50 MB to render *a single web page*) I (or Nexus) might be crucified because of this... which is why I am adding options to the Performance vs. Memory Usage dialog to optionally disable most of these caching.

Do so at your peril, however.

Caching of the main bitmap sheet cannot be disabled of course (some caching still has to be done, otherwise the effects would be impracticable to use), but disable caching of the fade in/fade out bitmaps and the performance hit will be HUGE. Caching of the scaled down bitmaps can also be disabled, and the hit for this will already not be so significative.

On the other hand, effect animation bitmaps are now shared by all docks and the Shelf. If before each dock would have its own copy of an effect animation cached in memory, even if the effect was the same for all of them, the same cached bitmap is used for all of them now.

Looks really good, Jorge!

Are you sure you read all that?

Anyway, I ended up adding total control on how the animations are cached via the Performance dialog.

The setting with the highest impact is the 'Disable effect pre-processing'.

This controls if the fade in and fade out animations of certain effects (only the new effects will be affected by this, except for Smoke because it now also fades out at the end) are pre-rendered or built on-the-fly.

Leaving it enabled can mean up to 3 times more memory usage for that effect, but the effect will be played as fast as it possibly can. Disabling the option reclaims a lot of memory but causes a MAJOR slow down of that effect.

Then you have three more rendering options which tie quality, speed and memory usage together. Their impact is not so severe.

You can cache animated effects using:

a) original resolution only (slower, better quality, higher memory usage*)
b) icon resolution only (faster, worse quality, lower memory usage*)
c) both (fastest, maximum quality, highest memory usage)

* if all docks have the same icon size.

Previous versions of Nexus, etc, were using only option b), but the effect was individually cached per each dock and Shelf. Now, if the dock and Shelf share the same icon size, only one copy of the effect at that size is kept in memory, thus at least halving memory usage. Of course, this is negated if each dock/shelf has a different icon size, in which case you would be better off using option a).

I've actually made option b) the default since it's what was used before.

c) is the one that offers the highest memory usage, but also the highest speed and rendering quality for magnifying docks (you can really see the difference in the quality of the details of the animation when holding the mouse pointer over a magnifying icon).

Beta 2 has been released.

This ones were added after beta 2:

20. Added new 'IP Lookup' internal command. Returns your public IP address as well as your current location (city, country) plus Latitude and Longitude coordinates.

21. Added new option (off by default) that can speed up icon drawing (and thus the speed of the dock) by a factor of 12 or more. Yes, you read that right.

This works by double-caching icons: one cache holds the icons in their original size (e.g.; 128x128, which already happens) and another the same images in the size used by the dock when the icons are not being magnified (normally 48x48).

For you to understand how much impact this has:

When the dock is magnified, only 3 to 4 icons at a time have sizes greater than the normal, non-magnified, size.

For icons to look good when fully magnified (i.e.; when they are rendered at 128x128) the provided images must/should be at least that big. The problem is when you have to render those huge images into the non-magnified icon size (48x48). For them not to look like crap at the smaller icon sizes, the big images must be re-sampled on the fly onto the smaller sizes with high quality bicubic interpolation filters.

This re-sampling (i.e.; drawing a 128x128 icon as a 48x48 image with good quality) takes a lot of time in comparison to the time taken to render an image that is the same size as the destination image.

To give you a real world example: it takes 1,787 ms (1,7 seconds) to render 10,000 times the same 128x128 PNG icon as a 48x48 image. In comparison, rendering a 48x48 image 10,000 times at that same size (48x48) only takes 128 ms because no re-sampling needs to be done.

That's right, it's nearly 14 times faster!

So, the trick is to double cache the icons in the dock: one cache uses the original icon size so the icon will look good at whatever size it's drawn, and another holds high quality copies of the same icons previously re-sampled down to 48x48 (or whatever the size of the non-magnified icons is).

If the icon that needs to be drawn is exactly 48x48 in size, then we use the copy in our second cache instead of the original larger image, thus avoiding the need to re-sample the original image. We only use the larger size cache for drawing icons that are currently being magnified (which will usually be no more than 3 or 4 at a time).

And if you think 10,000 redraws is a lot, think again. Move the mouse pointer fully across a dock with 35 icons, plus an animated mouse over effect like Swirl, and you get about 2,500 independent icon redraws during that time alone (I just counted them). And I'm not even taking into account the independent icon reflections, which also need to be re-drawn 2,500 times.

So, we shaved at least *half a second* from the time it would take to finish all animations without this method - in a single pass of the mouse pointer.

This is how dramatic the speed increase can be.

Because of the memory usage zealots, this method will be off by default, as I mentioned above. But if you care more about performance than memory usage (which in reality will be negligible in the grand scheme of things), then this will be a MUST ENABLE setting. Especially on weaker CPUs - you will feel a huge difference in the responsiveness of the dock, more so with animated effects such as swirl, magic, water, etc...

Made some more real world tests to the difference between having the new 'Enable double caching of icons' setting on or off.

Although the speed difference in terms of drawing images is indeed HUGE, image rendering is not the only thing that is happening when the dock is being redrawn.

So, in terms of real world usage. Dock with 29 icons redrawn 1,000 times:

With Double Caching off: 14.6 seconds.
With Double Caching on: 8.9 seconds.

So, 40% faster. Still not bad at all.

Jorge, I'm trying to turn on double icon caching, but, um, I can't find where to DO that.

I just found THIS in another thread:


When I go to the Performance Settings, I don't HAVE "Enable double caching of icons . . . " as an option. I checked and I'm using 16.2.

I added that AFTER beta 2.

New and final beta (beta 3) just released!