icon.library 46.4 test versions

[PeterK]

Update to icon.library 46.4.383:

This version will avoid the data copying to and from the gfx-card with the original number of bytes/row. It's always working with the reduced image width.

Please compare the speed of 376, 378, 381, 382 and 383 on your system with the script from daxb and report the results. THX.

[pawelek]

I updated the results. http://eab.abime.net/showpost.php?p=...postcount=1059

[PeterK]

Thanks a lot for all your measurements and the nice table of results !
Your list gives a good example how the speed has improved step by step.

[Retrofan]

Thanks a lot PeterK for the latest updates that make it so fast.

I have a question for Pawelek. What is the percentage of speed improvement between the latest icon.library on Aminet (I don't know the version) and this last, making the comparison with icons with the 3.5 format ?

Thx a lot for your tests .

[pawelek]

Originally Posted by Retrofan

What is the percentage of speed improvement between the latest icon.library on Aminet (I don't know the version) and this last, making the comparison with icons with the 3.5 format ?

Between Icon.library 45.10 and icon.library 46.4.x is a big chasm.
icon.library 45.10 (version of the os3.9) is a mistake, she does not use FastRAM.

[PeterK]

@Retrofan
On my WinUAE system with OS 3.9 the current icon.library is about 23.5 times faster than v45.1. But I guess, you are more interested in benchmark results from a real Amiga system. ...

@pawelek
The last iconlib of OS 3.9 was v45.1, and of course it also uses FastRam if you change the settings in Prefs/Workbench, but it does not use only FastRam, it still allocates some ChipRam too for creating masks, without any good reason.

[Retrofan]

Sorry, it seems I don't seem to express well what I want to say. I was referring about the latest icon.library on Aminet by PeterK, that is 46.4.374 and this last, and comparing using only icons in the 3.5 format.

[PeterK]

Sorry Retrofan,
seems I didn't read your posting carefully enough, and since pawelek was referring to v45.1(0) I started to do the same mistake. I regret that I cannot offer you any results comparing 374 and 383 on real Amiga systems atm.

[pawelek]

CrystalIcons icon collection: (Blizzard 1260/64mhz)

icon.library 46.4.374
Total: 10.90
Average: 0.990
---------------------
icon.library 46.4.383
Total: 10.70
Average: 0.972

[PeterK]

Update to icon.library 46.4.384:

(In advance to the soon coming Aminet upload) I've removed a MUL instruction and replaced some stack access by register usage in the direct drawing routine. Please check the icons for any cut-off edges and post your benchmark results if you like.

[pawelek]

performance similar (Blizz1260/64mhz, Radeon):

Ken's Icons v4 PNG icon collection
icon.library 46.4.383
Total: 48.72
Average: 9.74
----------------------------
icon.library 46.4.384
Total: 48.66
Average: 9.73


CrystalIcons icon collection:
icon.library 46.4.383
Total: 10.72
Average: 0.974
----------------------------
icon.library 46.4.384
Total: 10.74
Average: 0.976

[PeterK]

Update to icon.library 46.4.384_mul:

It seems that replacing the MULU.W was not a good idea for 68060 CPUs, since they need only 2 cycles instead of 26 with a 020 CPU. Thus, I reverted this instruction replacement to see if the performance would get better now.

Many thanks again to pawelek

There will come out a much better version soon on Aminet.

[pawelek]

again all three, because hundredths of results depend on any change in AmigaOS

(Blizz1260/64mhz, Radeon):

Ken's Icons v4 PNG icon collection
icon.library 46.4.383
Total: 48.80
Average: 9.76
----------------------------
icon.library 46.4.384
Total: 48.94
Average: 9.78
----------------------------
icon.library 46.4.384_mul
Total: 48.86
Average: 9.77
----------------------------
icon.library 46.4.385
Total: 48.50
Average: 9.7
----------------------------
icon.library 46.4.386
Total: 48.52
Average: 9.704



CrystalIcons icon collection:
icon.library 46.4.383
Total: 10.80
Average: 0.981
----------------------------
icon.library 46.4.384
Total: 10.84
Average: 0.985
----------------------------
icon.library 46.4.384_mul
Total: 10.86
Average: 0.987

the results are very similar...

[Retrofan]

Originally Posted by pawelek

CrystalIcons icon collection: (Blizzard 1260/64mhz)

icon.library 46.4.374
Total: 10.90
Average: 0.990
---------------------
icon.library 46.4.383
Total: 10.70
Average: 0.972

Thanks a lot pawelek. What I didn't remember is that the latest icon.library for my AmiKit Real version is "- UPDATED: IconLib 46.4.343 by Peter Keunecke". So even previous than that (sorry). Since time ago I don't add the icon.library to my updates and I just wait for them to be added with the Live Updates -online- of AmiKit (of course the Full install has the latest icon.library from the latest Live Update).

And with my next AmiKit Real 1.1 update I will add a program by Thomas (thanks again master) to convert (if you like) all of the icons (they are Ken's icons) to the 3.5 format, so the speed improvement has to be VERY noticeable. . That's why I want to know about the percentage of speed improvement.

[PeterK]

Sorry Retrofan,
but my experience with AmiKit 1.7 and the LiveUpdate is that none of them ever installed the latest icon.library correctly. Look into the installer scripts, what you will find there concerning icon.library is either outdated or commented out.

@pawelek
Thanks again for your results. It seems that 383 was the fastes version up to now. I don't know why 384 was slower. But tomorrow you may find a turbo release at Aminet.

[Michael]

@OpenWin problems.
1. Need to set flag not to copy icons to ram. Otherwise it fails here most of the time with all sorts of errors. eg: Ram:Kens_Icons/DH0:Kens_Icons/
Is it a proper path or just info what was copied? Because it always complains dir not found.

2. For Dopus test to work we have to check if the drawer has an icon, if it does not we should ask to add one, or do it silently. (kens pack is example)

3. A small potential problem with DO is a too small delay between the tests. Since the first window has not closed yet when the next one opens and starts the test.

Otherwise all seems to work fine, including WB+DOPUS question
One thing... If we select WB or DOPUS, can we force that screen to front ?


@Benchmark
Some result of my 16bit CGX/060

Ken's Icons v4 PNG icon collection
icon.library 46.4.378
Average: 10.94
----------------------------
icon.library 46.4.384
Average: 10.90
----------------------------
icon.library 46.4.384_mul
Average: 10.94

CrystalIcons icon collection:
icon.library 46.4.378
Average: 1.52
----------------------------
icon.library 46.4.384
Average: 1.48
----------------------------
icon.library 46.4.384_mul
Average: 1.50


Now compare WB 45 v WB 50 v DOPUS 5.82 (icon.library 46.4.384)
Crystal: 1.46 v 1.48 v 7.12
Kens: 10.88 v 10.90 v 16.40

WB is slightly different since something is happening there, but DOPUS is a failure.
Playing with some of the icon settings in DOPUS did not give any improvements, only slowdowns.
I guess it is taking too much in analysing and drawing icons (no direct drawing and a big processing chain)
that give an extra 5.5 secs for both tests.

[daxb]

1: I saw this error here one time but couldn`t reproduce it. However, I`ve changed some things already what should fix this.

2: It doesn`t make sense using a drawer without an icon because DOpus (I guess WB too) take at least window size information from it. Add an icon automatically just uses a default window size what may fit or not.

3: Only the very first open/close, during all passes or the whole test?

At the moment "screen to front" works but OpenWin window is on the screen where it is lauched from.

[PeterK]

@Michael

...but DOPUS is a failure. Playing with some of the icon settings in DOPUS did not give any improvements, only slowdowns. I guess it is taking too much in analysing and drawing icons (no direct drawing and a big processing chain) that give an extra 5.5 secs for both tests.

Thank you for your test results!
With AmiKit 1.7 DOpus5 needs about twice as long for PNG icons here. Are you sure that DOpus5 is not using the direct drawing on your system, or in other words, is the icon quality less like it is on the 256-color screemodes? DOpus5 should use the direct drawing via my built-in graphics.library patch for the blitter calls. I guess, DOpus5 is slow, because it uses internal icon drawing functions and that is also the reason why the icon.library can not delay the color mapping for the icon images like it is done on the Workbench.

The upcoming Aminet release should give all PNG and OS4 icons a boost, even on DOpus Magellan II

[Michael]

@daxb

RE:2 - Kens pack does not have an icon for the drawer in the archive, and unless you add it after unpacking the benchmark will not work in DOPUS, that's why we need to check this condition

RE:3 - I believe for every path, since I can drag the window to a side and see how a new window is open and then a few moments later the old one is closed (memory freed with a delay I guess)

@PeterK
Dopus has a few tweaks settings for icons, and it's difficult to say what is going on.
But definitely enabling custom draw, custom drag and flameless transparency options make things worth, slower and cosmetically ugly (I guess it was good for old icons and AGA modes combo)
As for quality, I can't tell, they look all gorgeous.
On the other hand the pen usage in DO is higher with your lib then with the classic OS3.9 icon.lib when the worst/bad colour mapping is used. For Crystal pack 60 free pens V 20 free pens. PS: Tried to test DO with old icon.lib and Kens pack, and lost patience, it was sooooo slooooww ;-) I love your work.

[PeterK]

On the other hand the pen usage in DO is higher with your lib then with the classic OS3.9 icon.lib when the worst/bad colour mapping is used. For Crystal pack 60 free pens V 20 free pens.

That's correct. My color mapping code tries to get as much pens as possible, because that gives the best quality for the AGA systems. It leaves only about 20 pens free for other applications, which sometimes want to obtain exclusive pens. Unfortunately, as I already said, I cannot disable the color mapping by delaying it when the direct drawing is used on graphics cards. On WB this is possible and keeps a lot more pens free or at least unblocked, so that they can be released with a WB-reset.

Icon.library 46.4.385 has been released on Aminet now. Enjoy it