icon.library 46.4 test versions

[PeterK]

Yeah, strange! I can reproduce it with DOpus5's icon info. But CopyIcon from Stephan Rupprecht works correctly. Use that!

[Michael]

Another interesting case...

WB
virtual def_icon assigned to a file
icon has a tool set to an arexx script file to be run as shell process

Now, if the icon is virtual (transparent) and we click it we get an error,
tool not found please select a new one.

If we snapshot the icon to give it a real icon with same setting,
clicking it will run the rexx script and do what's required from it.

(processfile.rexx (mod by Stephan Rupprecht))

[PeterK]

Is the type of the DefIcon "Project" and the default tool Path/ProcessFile.rexx? And where can I find "ProcessFile.rexx"?

I've tried a DefIcon ENVARC:Sys/def_amigaguide.info with the default tool "Multiview" and that works at least for ghosted icons, but never tried an Arexx script yet. It's probably not a bug in icon.library, looks more like a problem in the AmigaOS and Arexx concept ?!

[Michael]

Solved!
Looks like the CLI argument did not stick the last time I have tried it, since in workbench mode it gives an error but works ok now with the proper settings saved in ENVARC:

[PeterK]

Icon.library 46.4.464 has been released on Aminet now.

[indigolemon]

Installed - trying your new variation (SB020) - no problems so far. Thanks for all the work you put into this

[Retrofan]

Excuse me: LD020 and SB020. I don't see what are they in the instructions.

[PeterK]

LD = Line by line direct Drawing
SB = Soft Borders with 50 % transparent pixels
The differences to the 68020 version are restricted to the direct drawing on Hi/TrueColor screens.
http://eab.abime.net/showpost.php?p=...postcount=2009

And NO, it's not a new 68k CPU type !!

[PeterK]

Update to icon.library 46.4.465:

1.) For drawer names with an appended "/" the slash will be removed before the ".info" extension for the icon names is added, because nobody wants to access "drawer/.info" which would be mapped to "ENVARC:Sys/def_drawer.info". This sometimes has happened with ContextMenu, for example.

2.) Calling IconControlA(GetImageData2) will now also create the delayed planar image which is required by the original PowerIcons patch 1.06 for icon dragging. You don't need to call "NoDelayedImage2" anymore and after disabling PowerIcons the delay is immediately working again. Greetings to Elena

[PeterK]

Update to icon.library 46.4.466:

Some experiments with the color reduction of OS4 and PNG icons. I hope that the quality is minimal better in some cases and that the code could also be a little faster on real Amiga CPUs, because I have replaced -(Ax) predecrement addressing by (Ax)+ postincrement instructions in the main loops. This makes no difference under emulation like UAE, of course. Feedback is welcome.

[Michael]

PeterK, we have a big Bug!

Trash icon types are broken.

ProcessIcon, DO5 icon info what ever, convert Drawer to Trash type results in crap ;-)

[PeterK]

Hi Michael,

this seems to be a problem of DOpus5 icon information, because it creates a trashcan icon in T: like DOpus-12345678-tmp.info, but it also wants to access the drawer DOpus-12345678-tmp, which it can't find when calling edit.

Strange thing: it works with a drawer icon under DOpus and it also works for trashcan icons with OS 3.9 WB icon information. Looks like another goodie of DOpus5.

[Michael]

40 prefs icons for OS4 loaded from disk CGX 8bit test

v465 - 4.60 sec
v466 - 4.20 sec

I'll say a good noticeable improvement.

[PeterK]

Thank you for posting your results. You're the first, Michael !

Which CPU is that? I think the highest improvements are possible with 020/030 and less with 040/060. Nothing with WinUAE or Amithlon.

[Michael]

That was on 060, and under DO5, which is also important to note.
In 16 bit modes the difference is 0.02 (within error tolerance)
Obviously the algorithm is not required there.

[PeterK]

Originally Posted by Michael

In 16 bit modes ... Obviously the algorithm is not required there.

No, the color reduction for OS4 and PNG icons is always required by my library, but not under AfA_OS.

[PeterK]

Update to icon.library 46.4.467:

Two small bugfixes: A different size of the first and second image of PNG icons was not detected. The second image is dropped now and replaced by a darker copy of the first image with a glowing effekt. - Editing trashcan icons from the information menu under DOpus5 didn't work because the icon type of the temporary file in T: was set to 0 instead of 5. Loading failed with a "wrong type" error.

[Michael]

Nice work.

Some new benchmarks, 16bit test CGX/DO5

v465 - 4.88 sec
v467 - 4.72 sec
v467SB - 5.00 sec

So there is some speed-up on 16bit too, just not as noticeable

[PeterK]

Originally Posted by Michael

Some new benchmarks, 16bit test CGX/DO5
v465 - 4.88 sec
v467 - 4.72 sec

Thanks again, these results are much closer to what I've expected than the unbelievable 10 % speedup that you've posted for your 8 bit benchmarks before.

I'm still waiting for some benchmarks from 68020/030 CPUs for PNG or OS4 icons. I think these CPUs should gain more relative speedup than 040/060. (Uploaded 46.4.465 again, just for comparison)

[PeterK]

Update to icon.library 46.4.468:

The Ram Disk icon is now automatically copied to ENV:Sys/def_RAM.info and ENVARC:Sys/def_RAM.info as soon as any changes to the icon position or to the window settings are made. Icon Information (RAWBInfo and SwazInfo) is supported too, but needs DefIcons running. It's not required to use MakeLink. But this works only on OS 3.5/3.9. The ghosting for the Ram Disk is always off now.