icon.library 46.4 test versions

[AMIGASYSTEM]

Originally Posted by kolla

the DefIcons editor of OS3.9 is not elegant or easy to use at all.

Yes I know the publisher is not friendly, I have them Def_Icon i configure them to my hand

Never worked? What do you mean? All you do is load it with LoadModule to replace the layers library in the kickstart

Yes, i was already using LoadModule in my startup and I added the layers.library, but I did not notice much difference in speed at least with AFA OS, i thought he did other things

[kolla]

Originally Posted by AMIGASYSTEM

I do not know the variable, Dopus5

All variables are described in the guide, under "Variables" on the first page.
But I was wrong, it is not a variable, it is a simple setting in the Environment settings - "Use Workbench icon positions":

[Michael]

Anybody got that layersbench script ?

PS: WBRun has different versions and depends on a library that can also be different
and some versions will refuse to work with DO5 if they use OS39 WB functions only

[PeterK]

Originally Posted by Michael

Anybody got that layersbench script ?

Sorry, no benchmark, but I've seen a video clip on YouTube showing a simple window open test, where ThoR's layers.library was 104 times faster than the original.

Btw, I'm still working on your "Volume" problem. Found already some reasons for this issue, but I had not enough time the last days to fix it completely, because I added the new function BumpRevisionLength() for OS 3.1.4 and had a lot of discussions with ThoR about the details. And I also had to improve my DOpus5 task detection, because that name depends on the program name. It's all in WIP state now.

[AMIGASYSTEM]

Originally Posted by kolla

it is a simple setting in the Environment settings - "Use Workbench icon positions":

Yes, i know, I had already set that option

[SnkBitten]

Originally Posted by Michael

Anybody got that layersbench script ?

PS: WBRun has different versions and depends on a library that can also be different
and some versions will refuse to work with DO5 if they use OS39 WB functions only

I found an old thread with some layers.library benchmark tests. Most of them I had to create myself though as the links were dead but the discussions carried most of the scripting in them.

Running the test on my Amithlon system showed a tremendous gain with layers.library over the stock one. It's a must have now on my Amiga's and Amithlon systems.

I'll see if I can find the test files I created. It's been a while and I've rebuilt my systems a few times and may have lost them.

[daxb]

Originally Posted by Michael

Anybody got that layersbench script ?

I'm not sure but maybe it is good enough for a practical benchmark test to write a small ARexx script for OS3.9 (see ARexx.doc for how to open/close, change size and position of a window). If the ARexx overhead don't eat the differences it should work.

[kolla]

Originally Posted by daxb

I'm not sure but maybe it is good enough for a practical benchmark test to write a small ARexx script for OS3.9 (see ARexx.doc for how to open/close, change size and position of a window). If the ARexx overhead don't eat the differences it should work.

You just described the original benchmark script

[SnkBitten]

Originally Posted by Michael

Anybody got that layersbench script ?

layersbenchmark.lha uploaded to the Zone.

a script that runs etime and a few arexx scripts and then etime again. Run it with the stock layers.library then loadmodule layers.library and run again.

[daxb]

I had a look at layersbenchmark.lha and I think it is not a good test for layers because it only opens drawers (with icons), counts the amount and the overall time. I would at least avoid window contents (icons, text list) and do some moving, front/back, zoom, resize and overlapping actions. Using TIME() for measurement avoids the need of external timer and is more flexible.

[PeterK]

Originally Posted by daxb

I had a look at layersbenchmark.lha and I think it is not a good test for layers because it only opens drawers (with icons), counts the amount and the overall time. I would at least avoid window contents (icons, text list)

But without icons it's becoming off-topic here.

[Michael]

Real Life Real Hardware test....

This actually does a mixed benchmark of layers and icon library.
Icon lib takes the most time for sure, a pure layers test needs a program that opens blank windows and shuffles them a bit

Anyway, the results:

30 system drawers opened/close with a mix of Glow and MWB icons

Layers 40
CGX/16b - 15 s
P96/16b - 18 s
AGA/32c - 30 s

Layers 45
CGX/16b - 15 s
P96/16b - 15 s
AGA/32c - 28 s

Notes:
CGX uses superlayers by default, so the performance in this tests seem to be similar
P96 without v45 makes solid window moving flicker, with v45 feels smoother and no flicker
AGA - you can't open too much, or you would loose chip ram, or need to use fblit

Another interesting note to note is when you run DO5 on WB or WB on DO5 screen,
the performance of icon lib is a bit slower, due to extra checks it makes, resulting in layers bench 15 -> 20 sec

[PeterK]

Originally Posted by Michael

Another interesting note to note is when you run DO5 on WB or WB on DO5 screen, the performance of icon lib is a bit slower, due to extra checks it makes, resulting in layers bench 15 -> 20 sec

Btw, I made another small mistake in 481 concerning DOpus5 using the LayoutIconA() function. This makes icon loading on DOpus5 a little slower again, because it can do its stupid remapping of the icons on the same screen again, and you won't get free pens back. I'm wondering why you didn't complain about it yet?

Your volume problem seems to be fixed now, but I still coundn't find the reason why the "dopus_disk_change" task sometimes (unpredictable) displays all disk devices and all their volumes (even the hidden ones) suddenly as kickstart icons (b/w floppy images). After clicking on "Icon Reset" it's all back to normal. It must be a DOpus5 bug, I guess.

[Michael]

Was somewhat busy with other tasks and did not use icons much, but now I see and that's a bit frustrating that we are moving in circles

[kolla]

It's a great tool to demonstrate the difference between layers.library v40.1 - 7 minutes, vs. V45.19 - less than 7 seconds, on the exact same system, with all windows having exact same content.

[daxb]

Originally Posted by PeterK

Your volume problem seems to be fixed now, but I still coundn't find the reason why the "dopus_disk_change" task sometimes (unpredictable) displays all disk devices and all their volumes (even the hidden ones) suddenly as kickstart icons (b/w floppy images). After clicking on "Icon Reset" it's all back to normal. It must be a DOpus5 bug, I guess.

Oh, you fount the DOpus5 bug that displays all devices/volumes, great. Here it happens very seldom about on time every 2 years. I always did a system reset when it happens. What do you mean by "Icon Reset"? If I ever see the bug again I would like to try it.

[Michael]

Originally Posted by kolla

It's a great tool to demonstrate the difference between layers.library v40.1 - 7 minutes, vs. V45.19 - less than 7 seconds, on the exact same system, with all windows having exact same content.

The demo video is not fair, there is some other problem on that system or some very old rtg library or wb lib in use, with all modern updates installed the differences are minimal in real use scenario. It could also be related to how uae works with some odd cpu settings.

[PeterK]

@daxb
No sorry, I said that I could NOT find the reason yet. There is a DOpus5 menu entry for icons that is called "reset" (Piktogramme zurücksetzen). This issue is caused by "dopus_disk_change", but I cannot reproduce it reliable. DOpus5 uses timers to check for inserted or ejected disks. I think something goes wrong with this internal process notification. SnoopDos shows you that "dopus_disk_change" wants to display Kickstart icons instead of the real existing icons. Very strange!

Could be a fight between WB and DOpus5, both are trying to display the inserted floppy disk at the same time?? Any other idea?

I think this is the point where something goes wrong, because DOpus5 tries to use #COPY_DIR and Workbench always flushes the buffer:

1987  [3] Workbench     #FLUSH       (None)                                  DH0        OK  
1988  DOpus5            #COPY_DIR    101A9EB1                                DH0        OK  
1989  [3] Workbench     #FLUSH       (None)                                  DH0        OK  
1990  DOpus5            #COPY_DIR    10194A0F                                DH0        OK  
1991  [3] Workbench     #FLUSH       (None)                                  DH0        OK  
1992  dopus_disk_change #COPY_DIR    101AAA19                                DH0        OK  
1993  [3] Workbench     #FLUSH       (None)                                  DH0        OK  
1994  dopus_disk_change #COPY_DIR    101AB5E9                                DH0        OK  
1995  [3] Workbench     #FLUSH       (None)                                  DH0        OK  
1996  dopus_function    #FREE_LOCK   101ACE1B                                DH0        OK

[daxb]

I meant that you found the causer "dopus_disk_change", not the exact bug. I never found out what action I need to do to show the bug. It just happened and I didn't knew why (nothing to reproduce). I asked years ago but nobody couldn't tell me more about it. So you are much further then I was. And yes, strange bug.

[kolla]

Originally Posted by Michael

The demo video is not fair, there is some other problem on that system or some very old rtg library or wb lib in use, with all modern updates installed the differences are minimal in real use scenario. It could also be related to how uae works with some odd cpu settings.

OK - if you say so, prove it with a video then.