icon.library 46.4 test versions

[Michael]

It might be simpler to have a second script with additional questions.
I like what we have now, nice and simple, and nothing else.
Only new mod required is to support DOPUS too.

hint...

IF SHOW(PORTS, 'WORKBENCH') THEN
ADDRESS WORKBENCH 'WINDOW "'path$'" OPEN'
IF SHOW(PORTS, 'DOPUS.1') THEN
ADDRESS DOPUS.1 'lister new 'path$
EXIT

Otherwise we can go further and have a special pack of icons
with different types, so that the tools unpacks the pack to RAM:
and then does measurement for different icon types (classic, colourful, NI, os3.5, 4.0, png) each set will need at least 50 icons.

And even more, when finished it can create a GUI and show some comparison stats ;-)
A full blown test tool in arexx. That will be the day.

[PeterK]

@daxb
My conclusion is that your script did a good job for me as it is now and needs no changes. Nevertheless, you may think about the suggestions from Michael.

[Michael]

Pawelek: icon.library 46.4.376 (68020)
Average: 12.48 s
After conversion PNG icons into OS3.5 format:
Pass: 1: 1.24 s

Amazing!
I get 12.30 s v 2.60 s

How come you are 2 times faster with converted icons!?

[daxb]

I`m using OS3.1 with DOpus5 as WB replacement. I.e. the script for workbench (3.5+) doesn`t work here. So for testing I already did a dopus version. That version doesn`t work at PeterK`s enviroment (Amikit?) and I couldn`t figure out why (some dopus setting guessing).

[daxb]

IMHO the best would be you or someone else does a test icon set and send it PeterK for specification test. Later I`ll add to the script. DOpus5 and Ram: support is already done. About GUI... if you want some visual stats I would recomment to use a proper spread-sheet program.

[daxb]

Need some tester for Workbench and DOpus5. Now you have to choose a directory where at least on directory with icons is. Default test is now from RAM:. If you want to switch back to HD you have to change the variable "dest" to "1" in line 10 of OpenWin.rexx.

[PeterK]

I've just testet the new script with AmiKit 1.7 in the DOpus5 envirenment loading Ken's Icons v4 into RAM:

The behaviour was not as expected. After making a copy of Ken's Icons into RAM: the script startet to open the subdirectories instead of the basedir "OpenWinTemp", like "def_icons", "Drawers", "Prefs" and "Kens2013, which I also have additionally. Now the most interesting fact: for the first three subdirs it did not show the icons inside, but for "Kens2013" it just worked fine. I will try to find the readon soon.

The reason is that DOpus5 needs a drawer icon in the DiskObject() format instead of a PNG icon to be able to display the drawers contents with the OpenWin.rexx script. So, OpenWinTemp.info has to be a drawer icon with a DiskObject() structure which can be achieved by using the icon.library calls:
DiskObject=GetDiskObject(DrawerName)
PutDiskObject(OpenWinTemp, DiskObject)
FreeDiskObject(DiskObject)
Unfortunately, it doesn't help to copy the icon from the harddisk to RAM: and then convert it with Snapshot. The reason seems to be yet another secret of DOpus5.

In the Workbench environment, the script failed in line 52 with error 10/15: function not found.

[daxb]

For "the function not found" error (makedir() function) I forgot about rexxsupport.library (libs must be add ) I use because here it is always in the list of libraries. However, try the updated script.

The "how to access icons" behaviour has changed as you noticed. It should (only) work this way:

E.g. you have icon packages like "def_icons", "Drawers", "Prefs" and "Kens2013" then you choose "testicons" dir vie requester. Btw. spaces in dir name isn`t supported, so "def icons" woun`t work for example.

Work:testicons/
  |--def_icons
  |--def_icons.info
  |--Drawers
  |--Drawers.info
  |--Kens2013
  |--Kens2013.info
  |--Prefs
  `--Prefs.info

If that doesn`t work, please let me know. Notice that informations are taken from def_icons.info, Drawers.info, Kens2013.info and Prefs.info.

Edit:
About the DOpus5 icon behaviour it might be good if the dev team of V5.9x just use your icon.library in the future. About V5.82 I wouldn`t care.

[PeterK]

Update to icon.library 46.4.377:

This version was buggy. Please delete it !

[AGS]

Hi, thats funny, I did the same with the pngflux.library today. However there it was a more than 50% speedup!

[PeterK]

Yes I know, I've read that, and that's why I tried the same
It seems, that it was the bottleneck in your library, but not in mine.

When using the row based loops I also scanned every line from the start and from the end towards the middel for subsequent transparent pixels and removed them from the calls to ReadPixelArray() and WritePixelArray(). Since icons usually have a lot of these transparent background pixels this was a nice speedup for the row based processing, which will rarely occur with normal PNG images like pictures.

[AGS]

I don't really understand what you mean but it sounds like good or an overhead, dunno.

[PeterK]

What I mean is, when for example an image line starts with 20 pixels being just a 100 % background, why should I change them. In such a case I started the ReadPixelArray() and the WritePixelArray() call with the 21'st pixel of the line. So there are 20 pixels less to process at all. The same happened from the last pixel of a line backwards to the middel. Transparent pixels were simply skipped. Of course, this trick can't be done anymore when the pixel array contains the complete image.

[pawelek]

New speed test with overclocked processor (script OpenWin.rexx)
Ken's Icons v4 PNG icon collection copied to the Ram disk.

Overclocked processor Blizzard 1260/64 Mhz, Mediator,Radeon 9250

icon.library 46.4.373
Total: 53.48
Average: 10.69
--------------------------
icon.library 46.4.374
Total: 53.38
Average: 10.67
--------------------------
icon.library 46.4.375
Total: 52.80
Average: 10.56
--------------------------
icon.library 46.4.376
Total: 48.80 s
Average: 9.76 s
--------------------------
icon.library 46.4.378
Total: 48.74 s
Average: 9.74 s

[AGS]

Why not? Here is my func. All you have to do is to check if the alpha value you read is $00, then skip the muls and divs! Not? You also can take an alpha value of $FF as a special case where you just copy a pixel.

calc_pixels	; apply ARGB data onto RGB data

		moveq	#0,d0			; image
		moveq	#0,d1			; screen
		moveq	#0,d2			; alpha
		move.w	#255,d3

.loop		move.b	(a0)+,d2		; get alpha value

		move.b	(a0)+,d0
		move.b	(a1),d1
		sub.w	d1,d0
		muls.w	d2,d0
		divs.w	d3,d0
		add.w	d1,d0
		move.b	d0,(a1)+

		move.b	(a0)+,d0
		move.b	(a1),d1
		sub.w	d1,d0
		muls.w	d2,d0
		divs.w	d3,d0
		add.w	d1,d0
		move.b	d0,(a1)+
		
		move.b	(a0)+,d0
		move.b	(a1),d1
		sub.w	d1,d0
		muls.w	d2,d0
		divs.w	d3,d0
		add.w	d1,d0
		move.b	d0,(a1)+

		dbf	d7,.loop
		rts

[PeterK]

Thanks Andreas,
but I don't use real alpha blending like you do. There are no MULS and DIVS in my routine, just 100 % background, 50 % of bpth or 100% of the image.

Removed the iconlibrary 46.4.377 again. There seems to be a problem with DOpus5.

[AGS]

Why not? How much faster is that?

PS: I did the changes I suggsted in my lib and can see the gain in speed.

[pawelek]

Speed test with http://aminet.net/package/pix/gicon/CrystalIcons (script OpenWin.rexx)
CrystalIcons collection copied to the Ram disk.

Blizzard 1260/64 Mhz, Mediator,Radeon 9250

icon.library 45.10
Total: 417.52
Average: 83.504
----------------------------
icon.library 46.4.355
Total: 10.60
Average: 1.514
----------------------
icon.library 46.4.367
Total: 10.60
Average: 1.514
----------------------
icon.library 46.4.373
Total: 10.06
Average: 1.006
----------------------
icon.library 46.4.374
Total: 10.94
Average: 0.994
----------------------
icon.library 46.4.375
Total: 10.98
Average: 0.998
----------------------
icon.library 46.4.376
Total: 10.88
Average: 0.989
----------------------
icon.library 46.4.378
Total: 10.84
Average: 0.985

[PeterK]

Update to icon.library 46.4.378:

Argh
I've forgotten to set the memory type for AllocVec() in 46.4.377. Delete it!

Changed the direct drawing again by replacing the row based loops with a routine working on the complete pixel array at once. This requires to allocate and free larger image buffers, which can't be taken from the stack anymore, but it's at least 1-2% faster for TrueColor icons and up to 10 % or more for color mapped icons. In addition, it reduces the size of the 68020 version further. There are no functional changes in the 68000 version.

@daxb
Sorry, but your script seems to be unusable now. Under DOpus5 it says "No directories here. Choose the official test icon package!". Such a message is just annoying. And on the Workbench the script starts with its passes, but it seems to be in an endless loop of very fast measurements. I prefer to use your old script and maybe I will try adapt it for DOpus5 requirements if I have the time.

[PeterK]

Originally Posted by AGS

Why not? Here is my func. All you have to do is to check if the alpha value you read is $00, then skip the muls and divs! Not? You also can take an alpha value of $FF as a special case where you just copy a pixel.

calc_pixels    ; apply ARGB data onto RGB data
 
        moveq    #0,d0            ; image
        moveq    #0,d1            ; screen
        moveq    #0,d2            ; alpha
        move.w    #255,d3
 
.loop        move.b    (a0)+,d2        ; get alpha value
 
        move.b    (a0)+,d0
        move.b    (a1),d1
        sub.w    d1,d0
        muls.w    d2,d0
        divs.w    d3,d0
        add.w    d1,d0
        move.b    d0,(a1)+
....
        dbf    d7,.loop
        rts

Why not instead of dividing by 255 doing a multiplication with 257 and a simple swap of D0, which means dividing by 65536 ??

1 / 255 = 0,00392156
257 / 65536 = 0,00392150

And you can calculate alpha * 257 just once and re-use it for all three RGB components.
So, you will need only one LSL #8,D2 plus ADD and three MULS.L plus SWAP instructions, but no DIVS.W.