icon.library 46.4 test versions

[Michael]

Some speed tests for different conditions and different libs.
I think we should have a MWB speed test for completeness.
And maybe OS4 icons, and lower colour (64c Gi) 3.5 icon pack too.

[PeterK]

Hi Michael,

thanks a lot for that very nice benchmark comparison table !!
Btw, the last offical icon.library version is 45.1 and not 45.2. (Or where did you get that from?)

Concerning all your problems, freezes or crashes after screenmode changes under DOpus5, there is a simple solution which can be installed with FPPrefs v40.23 as you know:
SetEnv ENVARC:FullPalette/DOpusRPFix FULL

@Retrofan
Thank you for confirming that the icon dragging works under DOpus5 and FBlit on AGA screens. Btw, you should also have noticed a small speed improvement on AGA with the latest IconLibs. But plz, get offline (out of the internet) before you start any benchmarks.

[Michael]

DOpusRPFix is broken too, and for me screenmode changes work fine as long as there is no open window with 3.5+ icons.

Under DO changing from 16bit to 8bit can result in missing normal icons (selected images are available) for open windows with 3.5 icons only.

45.2 probably came with some patches or updates, I have a big collection of rare ones too but they are useless now. Your lib is like getting a new turbo card for AmigaOS!

[Retrofan]

Nah. Without internet it has been 11.08, 11.88 the second (always same drawer). And using Game Booster to optimize WinUAE it has been 10.38 and 10.02 the second. And this on my faster laptop.

How can I compare different icon libraries if I can not compare twice the same drawer with Openwin?

[PeterK]

@Retrofan,
how should I know what's running in the background on your PCs while you try to benchmark in WinUAE. If you've installed just half the number of kiddy toys on your PCs like you did in your AmiKit distro then your PCs will never run with full speed. Start a tool like ProcessExplorer and you will see what's going on in the background and which processes are consuming your CPU time.

@Michael
When you are changing the screenmode from Hi/TrueColor to AGA the icons get invisible because the colormapping has not been done before. I will to fix that if possible.

[HanSolo]

@PeterK Hope if you finish completly icon.library you start optimizing other amigaos libraries, right ?

[PeterK]

@HanSolo
I don't know, I've no plans yet. And I don't use the AmigaOS for anything at all except programming, not even my icon.library is used for displaying nice icons.

There is not much visible speed gain to expect from optimizing any other libraries or OS resources, because their functions are not called often enough to let even the best optimization result in a noticeable speed improvement. Do you want a particular library to be optimized?

[Michael]

picture.datatype might be interesting, the colour mapping, the dithering routines, other things... used for many things by the os.

[HanSolo]

@PeterK Cosmo abandoned optimizing amigaos libraries so mybe you can do. I think maybe exec.library could be improved and integrate some usefull patches like cosmo did.

[Tumo007]

Peter, How about workbench.library? I prefer 3.9 Workbench over all the other WB replacement but I find the file lister slow. It would be nice to add support for the mouse scroll-wheel.

[PeterK]

No guys, these large projects like exec.library, workbench.library or picture.datatype that's all no fun. Nothing I would ever start to code for. And I don't feel like doing anything big in the future. It's more likely that I say GoodBye to the AmigaOS sooner or later.

It would be nice to add support for the mouse scroll-wheel.

http://aminet.net/package/util/mouse/FreeWheel

FullPalette update 40.23 - AmiKit version
Author: Massimo Tantignone
Source: http://amikit.amiga.sk

This updated version of FPPrefs fixes the problem with DirOpus Magellan's incorrect usage of ReleasePen() that causes the freezes when reopening the screen.

To activate the fix, install the FPPrefs command and set and save a "FullPalette/DOpusRPFix" environment variable with the value "FULL". You can do it by executing the following command:

SetEnv ENVARC:FullPalette/DOpusRPFix FULL

It's still recommended to use this fix for DOpus5 to avoid freezes and crashes caused by ReleasePen() during screenmode changes. This fix is not perfect and Michael doesn't like it because it seems to prevent the release of pens, but I never had any problem with this fix.

[Michael]

Correct, I don't like it, since screenmodes are changed rarely usually for test cases,
but not releasing pens during normal life is a pain and gives more problems then benefits.
And the question is still open why some icon.libs seem to work fine without this fix.

[PeterK]

Originally Posted by Michael

And the question is still open why some icon.libs seem to work fine without this fix.

No sorry, with all icon.libraries which I tested so far (45.1/2/4 and 46.4.x) the system freezes after a screenmode change and brings Enforcer hits when this fix is not installed. (DOpus5.82 on CGX4/WB3.1, PiccoloSD64). And all are working with this fix installed.

[Retrofan]

On my AK Real version DOpus also uses to freeze after an screenmode change. Exceptions are when you aren't running AmiDock or LimpidClock, and you are better using just 16 colors and a not very large screenmode.

[Michael]

UPDATE DOpusRPfix !

As we have rediscovered DO MAG 5.82 has some problems with 3.5+ icons and screenmode changes.

Well, for me setting DOpusRPfix = NORMAL has been a positive experience.
1. DO no longer locks the colours forever, only the FullPalette locked colours and system pens are locked as they should be.
2. Screenmode changes start working with most icon libraries ;-)

There are a few side effects, like potentially discoloured icons in open windows, but only when you go down in colour depth, say from 16bit to 8bit.
Otherwise it seems to work like a charm

Updated docs to FullPalette from Massimo :-)

The DOpusRPFix option of FPPrefs was born from the discovery that DirOpus is
prone to crashing when closing and reopening the Workbench screen on OS 3.5+
systems. Furthermore, even when it didn't crash, it could easily make random
changes in the screen's palette colors, with ugly cosmetic results.

The problem is due to the fact that DirOpus sometimes releases pens it never
allocated in the first place, and therefore trashes the pen allocation table
of the screen. (It may be the consequence of a bug in the way DirOpus uses
the new icon.library functions of OS 3.5+ dealing with palette-mapped icons.)

The only way I found to fully work around DirOpus' incorrect usage of the
ReleasePen() function is preventing DirOpus from ever releasing pens, which
is certainly not nice, but (in my opinion) still better than having crashes
or color corruption.

That said, there is something you could try, in case it works better for you.

You can set the DOpusRPFix variable to NORMAL (instead of FULL). This tells
FPPrefs to *only* prevent DirOpus from releasing the pens that have been
locked with the FullPalette editor (as well as the first/last four, and the
three used by the mouse pointer). All other pens allocated by DirOpus will
be able to be released normally. This will still cure most of the DirOpus
bugs mentioned above, but some colors, mainly in OS 3.5+ icons, will still
be trashed by DirOpus. Only with FULL all colors should stay correct (at the
price of DirOpus never releasing any allocated pens).

[Michael]

@PeterK
Now with the above discovery, I have font the following interesting behaviour.
And potential idea for direct draw in DO!

1. We are still waiting for return of the missing icons when we switch screens from 16/24bit to 8bit (normal icons are missing, selected are ok)

2. Now what's even more interesting is that once we make a screenmode change from 16 to 24 bits, or just change the resolution, DO drops all used pens for icons in open windows, but the icons are displayed correctly. You can select/deselect them, and the draw correctly, and do not use any pens!!! Even if you load some other big icon pack, that uses all the pen colours, the previously open icons are not discoloured, they are rendered properly as if they are drawn directly and avoid pen colour allocation!
Only when you drag such an icon, you see some colour distortion.

[PeterK]

Update to icon.library 46.4.398:

Changing the screenmode under DOpus5 from Hi/TrueColor to 256 colors or less will display simple black masks of the icon images instead of nothing. You can remap these icons by choosing icon reset from the DOpus5 icon menu or by reopening the drawers. This fix makes the icon loading a bit slower again.


@Michael
please use the standard font size and don't shout here or start your own thread. Thank you !!

1. is done as good as it is possible without colormapping and C2P.
2. as long as you use screenmodes with 15 bits or more the direct drawing is always used and that can't show wrong colors (at least not with the special drag routines).

[Michael]

Sorry for being a bit over emotional, fixed.

As for icon remapping, I have not noticed any black masks, or I have missed something ;-)
For me the icons are displayed correctly and in colour.

Something I have noticed...

Speed wise, yes a small penalty
DO 8bit was 3.69 now 4.10
DO 16bit was 3.06 now 3.30
DO 24bit was 3.63 now 3.64 (no change?!).

Now what's really interesting is if you change the mode to the same one, the new test will be a bit slower DO 16bit was 3.30 and new one will be 3.54.

Another funny thing, is colour pen allocation in DO and WB differs!
Opened DO, then open WB on the DO screen.
Now open the sys: prefs/ folder in DO and in WB, in theory, same icons should give same results but no, in my case DO gives 51 free pens, WB opened folder 47 free pens. A bit odd.

But I am very happy now, it's near perfect now.

And with DOnoColourRemap my DO has always 180 free pens, just like WB, cool

[PeterK]

When changing screenmode from 15-32 bit to 8 bit or less you will see the black image masks as shown in the attachment. This only happens the first time when you reduce the screen depth (not after a reboot). There were no icons visible in 397 before. Strange that even the 8-bit mode is slower on your system now. I've to check that.

You can not compare the pen allocation of the WB and DOpus5 directly. Both use their own and different routines. There are hundred of small dependencies to solve for all possible cases that can occur and I'm glad that it works at all. Don't expect the settings for the color precision to be exactly the same for the WB and for DOpus5.

[PeterK]

Update to icon.library 46.4.399:

Changed the default configuration for the drawer flags in that way that PNG disk icons now will always show the DOpus5 lister toolbar, but drawer icons will still use the standard defaults without it (icons only).