icon.library 46.4 test versions

[Michael]

Originally Posted by PeterK

The behaviour of the icon.library v45.1 is the same. I don't know if I should change that. But I guess, you are right, it would be more logical to snapshot the window frame position and size only and not its icon, too.

It's probably done both together, because the whole DiskObject-structure is simply written back from memory onto the disk, and not just the particular data.

Tested DOPUS, and that works correctly (as expected), without saving the disk/drawer icon position, only the window settings.

One more question regarding colour pallet handling.
Do you use locked colours or only free pens and lock them yourself ?
Out of 256c how many pens do you obtain ?
And can the number of used or free pens be configured/limited by user ?
For example, for a 64c AGA screen I might prefer to have guaranteed 8 free pens or more, not used for icons, but eg. used for special things or extra MUI prefs.

[PeterK]

Originally Posted by Michael

Some updated results of my 16bit CGX/060
We see more speed!

Thank you for your results, Michael
What should I say now? Your speed gains for 386 are the first results that are pointing in the right direction, showing an improvement as intended. But all other benchmark reports are indicating speed losses from 385 to 386.

Do you use locked colours or only free pens and lock them yourself ?
Out of 256c how many pens do you obtain ?
And can the number of used or free pens be configured/limited by user ?
For example, for a 64c AGA screen I might prefer to have guaranteed 8 free pens or more

All pens that are obtained by the icon.library are shared pens and not for exclusive usage. When an icon makes use of an existing shared pen or obtains a new free pen then it always increases the reference counter for that pen by 1. As long as a reference counter is not back down to zero this pen can not be released by the system to the free pens again.

On 256 color screens I've adjusted the pen allocation procedure to leave approximately 16 - 20 pens free for other applications. But for screens with less colors this value is reduced to maybe just 1 free pen, because without doing that the icon colors would look much worse. Keeping 8 pens or more free is not practical. If you need 8 Colors for MWB or MUI then use FullPalette to set up the colors and to lock them and insert FPPrefs into your startup-sequence above IPrefs.

[Retrofan]

I've always seen first IPrefs then FPPrefs.

Edit: I've tried right now as you say and it works the same. I'm very interested in any change in the s-s because with Rainboot I have to be very careful with IPrefs.

[PeterK]

I'm not sure whether that really makes a difference or not. If FPPrefs starts before IPrefs it can lock the colors, so that IPrefs -> Palette.prefs cannot overwrite the colors anymore. But if IPrefs doesn't lock any colors then it won't make a difference when FPPrefs starts later and changes them again.

[Retrofan]

Really interesting. With Rainboot it has a lot of problems with IPrefs and you see them right after booting, with bad colors in icons or Amidock. I had already changed IPrefs and FPPrefs to start later and it was doing the trick to not conflict with Rainboot... but not always. I've tried right now rebooting about 15 times without problems running first FPPrefs, so I will keep them as you've said.

Thank you.

[daxb]

@Michael:
That works like expected. You get the message to add an icon because it is needed. As far as I can see there isn`t a possibility to add an icon with WB ARexx. Under DOpus5 it is possible but it would be just the default sized window. So it doesn`t make sense to add this to the script. However, you should copy the icon collection to HD, add an icon if not exist and size/fix the window. It is better/easier this way instead of just copy or depack icons to Ram: like you did.

@Retrofan:
You might have a look into FullPalette.guide. There you get some information you find interesting. E.g. this one:

"2) Insert into your Startup-sequence, IMMEDIATELY AFTER IPREFS"

[Michael]

Originally Posted by daxb

@Michael:
That works like expected. You get the message to add an icon because it is needed. As far as I can see there isn`t a possibility to add an icon with WB ARexx. Under DOpus5 it is possible but it would be just the default sized window. So it doesn`t make sense to add this to the script. However, you should copy the icon collection to HD, add an icon if not exist and size/fix the window. It is better/easier this way instead of just copy or depack icons to Ram: like you did.

1. After reboot the RAM drive is empty!
2. WB does not need an icon, DO does, and that is why it should add it.
Since adding it manually or automaticly will not make any difference.

So why the WB icon test dir window gets resized to minimal size?
So that we don't see how the icons are rendered?

[Michael]

Originally Posted by PeterK

What should I say now? Your speed gains for 386 are the first results that are pointing in the right direction

Just came to my mind... a land mark figure... 386

Originally Posted by PeterK

All pens that are obtained by the icon.library are shared pens and not for exclusive usage. When an icon makes use of an existing shared pen or obtains a new free pen then it always increases the reference counter for that pen by 1. As long as a reference counter is not back down to zero this pen can not be released by the system to the free pens again.

On 256 color screens I've adjusted the pen allocation procedure to leave approximately 16 - 20 pens free for other applications. But for screens with less colors this value is reduced to maybe just 1 free pen, because without doing that the icon colors would look much worse. Keeping 8 pens or more free is not practical. If you need 8 Colors for MWB or MUI then use FullPalette to set up the colors and to lock them and insert FPPrefs into your startup-sequence above IPrefs.

Hmm... So, do you use already available locked colours first? eg. my pallet has about 64 locked colours on boot. And only when a required locked colour is missing you allocate a new free one ? What tone tolerance?

I would really like to have some more control as to how much colour resources are given to the icon.lib. for eg. the MUI Busy.mcc requires a lot of colours for gradient busy, and sometime in my case it runs out of colours. Oddly enough wbpattern also runs out of colours when you change between 256c screenmodes (and my patterns only use ~32c) This happens if a drawer with a lot of colour icons was displayed before and the pens were used up. In general use my Gi icons use around 64 colours only, and I can leave with some quality loss for the really colourful icons that waste the free pen usage. That's why I am asking for some kind of ENV var setting if possible that will give some extra control on this behaviour.
eg. it can be a fixed number of free pens, or a percent of the pallet
(that will make it dynamic for 16-256c range)

Another possibility... If say we define 32c for free pens (then in 256c mode we get 32 fp, in 128c we get halfed (16), in 64 halfed again (8) until we get to 8c where we have 0 for obvious reasons)

[PeterK]

Originally Posted by Michael

Hmm... So, do you use already available locked colours first?

Yes, of course, all shared pens (locked or not) are compared for their color distance in the RGB-cube and the closest of them is used before any new color will be allocated as long as the color error is less than the tolerance.

... my pallet has about 64 locked colours on boot. And only when a required locked colour is missing you allocate a new free one ? What tone tolerance?

The tolerance for the color distance is not a static value and there is no number defined for the colors that have to remain free. The tolerance is a dynamic formular depending on the total number of shared pens and the number of free pens that are currently available. When the number of free pens goes down then the tolerance for using existing colors grows and the price for obtaining new pens gets higher. That's the way how ObtainBestPenA() works. You can modify this formular just a little in the Prefs/Worbench or Prefs/WBPattern settings for the color tolerance.

I would really like to have some more control as to how much colour resources are given to the icon.lib.

Sorry, there is no other way than changing Prefs/Workbench settings for the icon quality. But this will give you only a very few more free pens.

MUI Busy.mcc requires a lot of colours for gradient busy, and sometime in my case it runs out of colours. Oddly enough wbpattern also runs out of colours when you change between 256c screenmodes (and my patterns only use ~32c) This happens if a drawer with a lot of colour icons was displayed before and the pens were used up.

MUI should uses shared pens, too.
After changing the screenmode you could try to release pens with WB->Reset, but usually this should be done automatically by the Workbench already. If you're writing your own program then make a call to IconControlA() or LayoutIconA() with a screen=NULL in order to release all pens of a screen or an icon first before you call it again with the new screen. Read the autodocs, please.

In general use my Gi icons use around 64 colours only, and I can leave with some quality loss for the really colourful icons that waste the free pen usage.

Each of your GiIcons may use only 64 colors, but each of them has it's own palette (for every image in general), so the total number of required colors depends also on the number of icon images that are displayed on the screen. 10 icons with 64 colors can easily use all colors of the screen.

That's why I am asking for some kind of ENV var setting if possible that will give some extra control on this behaviour. eg. it can be a fixed number of free pens, or a percent of the pallet (that will make it dynamic for 16-256c range)

No sorry, you must learn to live with shared colors that hold not 100 % exactly the colors that you want to have (use ObtainBestPenA() to get the closest pen) or you must lock your colors with FullPalette early enough in the startup-sequence.

Another possibility... If say we define 32c for free pens (then in 256c mode we get 32 fp, in 128c we get halfed (16), in 64 halfed again (8) until we get to 8c where we have 0 for obvious reasons)

No, as I already said, don't try to use fixed palettes or locked pens for your programs. Use shared colors.

[Retrofan]

Originally Posted by daxb

@Retrofan:
You might have a look into FullPalette.guide. There you get some information you find interesting. E.g. this one:

"2) Insert into your Startup-sequence, IMMEDIATELY AFTER IPREFS"

Originally Posted by PeterK

I'm not sure whether that really makes a difference or not. If FPPrefs starts before IPrefs it can lock the colors, so that IPrefs -> Palette.prefs cannot overwrite the colors anymore. But if IPrefs doesn't lock any colors then it won't make a difference when FPPrefs starts later and changes them again.

Yes daxb I was supossing everybody including me had it there for something. The thing is that I never had had problems with IPrefs, but now from time to time I have them with Rainboot, so it's the best way to check the behaviour. What I know is that the latest (well, not so much) in the s-s for IPrefs the better to not conflict with Rainboot. Yesterday changing FPPrefs before I only had one booting with problems in the icons of Amidock in 30 bootings. I can try more things, like a Wait 1 between them and also a Wait 2 for Amidock, but now it isn't a heavy problem so occasionally.

And sorry for the offtopic.

[daxb]

Originally Posted by Michael

1. After reboot the RAM drive is empty!

Yes, except T, Clipboards and Env but I don`t know what do you want to say me with that.

So why the WB icon test dir window gets resized to minimal size?
So that we don't see how the icons are rendered?

The lock workaround for the WBTest is changed now by tomsmart1. Please let me know if it works for you.

[Michael]

Originally Posted by daxb

Yes, except T, Clipboards and Env but I don`t know what do you want to say me with that.

The lock workaround for the WBTest is changed now by tomsmart1. Please let me know if it works for you.

Cold boot, run script, get error below:
There is nothing in RAM!!! So icon check is wrong and fails

The drawer has no icon! Please add an icon for:
RamDisk:kens_icons_v4
0: Unknown command
0 - return code: 10

[Michael]

@PeterK

So the wb prefs icon precision has small effect on pen usage ? (when set to BAD)
Only the colour selection becomes faster? Or when we set to poor or netter more pens will be used? Which is logical, only why the wb icon lib has bigger colour tolerance for the bad setting ? I guess we need to know a bit more on the icon quality settings for the docs section.


Now the bad news.
Looks like 3.85 and both of 3.86 versions perform the same at 1.48 /10.84 seconds
actually the aligned version sometimes showed a tiny bit slower.

The best results were obtained when the test icon window was minimized.
For some reason it happens on unpredictable cases here.
And results do improve to 1.40/10.76 since less icons are actually drawn to screen.
So this is an important factor for benchmarking!
Almost pulled my hair out before figuring out why I lost performance ;-)

[Michael]

Just for extra detail, here is my palette
Some details:
first 4 colours are default wb
then we have 4 extra MWB/MUI colours
then we have a few pens from rainbow spectrum
with some colours from 'rebels' palette, 3 mouse pointer colours, and 3 extra greys.
finally the last half is a spread of all other greys, a gap (for mouse)
some more greys, 'rebels' colours and finally last primary spectrum that are also my system colours. RED for cursor, YELLOW for icon text, GREEN for glyphs.
The reason for such odd placement of colours and greys is when the numebr of screen colours is reduced the more important colours are kept locked.
The mid section is free. An evolution of several years.

[PeterK]

Originally Posted by Michael

@PeterK
So the wb prefs icon precision has small effect on pen usage ? (when set to BAD) Only the colour selection becomes faster?

Setting Prefs/Workbench icon quality to BAD is a special case for my icon.library. It enables the fast color mapping (or the grayscale mode). The fast color mapping uses a 512 byte cache for color assignments to the pens.

Or when we set to poor or better more pens will be used? Which is logical, only why the wb icon lib has bigger colour tolerance for the bad setting ? I guess we need to know a bit more on the icon quality settings for the docs section.

No, I don't like writing docs, since usually nobody reads them. Just play with the Prefs/Workbench settings to find out which of icon quality is the best for your demands.

Looks like 3.85 and both of 3.86 versions perform the same at 1.48 /10.84 seconds. Actually the aligned version sometimes showed a tiny bit slower. The best results were obtained when the test icon window was minimized. And results do improve to 1.40/10.76 since less icons are actually drawn to screen. So this is an important factor for benchmarking!

Yes, of course, the time for displaying the icons with DrawIconState() depends on whether they are inside of the visible area of a window or hidden in the scrolled out locations. WB won't call DrawIconState() for hidden icons. I don't know how DOpus5 handles this internally? Btw, 386_aligned was not optimal. Maybe, I will try again.

Concerning your palette problems, are you programming something or is it a problem to find out the right setup for the WB or DOpus5?

[daxb]

@Michael:
You mean the script quite direct after start without filerequester open? If so, please delete "ENVARC:OpenWin_dir" on your system and restart the script. If that doesn`t help I need debug output (set MyDebug = 2).

[Michael]

Originally Posted by daxb

@Michael:
You mean the script quite direct after start without filerequester open? If so, please delete "ENVARC:OpenWin_dir" on your system and restart the script. If that doesn`t help I need debug output (set MyDebug = 2).

The logic in your code is faulty.
Yes, deleting the envarc variable makes the script start, but only first time until a reboot and you have to delete the variable again.

Secondly why check for an icon if the directory does not exist in the first place?

And now even more fun. After successful run of your script for the first time,
go and kill the drawer icon for ken_icons pack in ram. And rerun the script.
Failure, no warning that icon is missing (in DOPUS mode).

And hence when we copy the files to a temp ram folder, it's better to check for the icon, and if it's missing, add one. Then it will run nice and smooth.

[Michael]

@PeterK:
Played some more with the quality setting in wb, and apparently it has no effect what so ever on my system. Speed is the same (within 0.02 error), and pen usage is the same! (For WB)

On the other hand DO behaves a bit different to WB, for some reason opening the same sets of icons on WB leaves me 66 free pens, while in DO only 25. Sadly, again for DO that it never releases a used pen, unlike WB that gives them back the second the icons are closed.

A bug in dopus or a missing feature?

UPDATE: However! Any triggering of IPrefs changes resets the free pen count! i.e. change resolution, change system font ets...
Maybe there is a way to signal dopus to free the pens when required, if it's difficult to predict when to do it, then maybe as an option do it on a time based period, eg. do a call every 10 secs, and ask it to release the unused pens.

[PeterK]

No, there is a difference in the way icon.library handles the color mapping for the WB and for DOpus5 when your system uses a gfx-card and the direct drawing. For the WB I can delay the color mapping of the first icon image until another process (not the WB task) calls DrawIconState(). Thus, this will need no pens at all except for the selected icon images, because the WB icon dragging will need the planar images then. But the color mapping for the selected images only happens when you click on the icons.

DOpus5 works a lot different. The direct drawing can only be achieved by patching the blitter calls, and unfortunately DOpus5 never calls the icon.library for DrawIconState(). For the blitter calls DOpus5 needs the planar images already. It will get them from GetIconTagList(). That's the reason why it will always require the pen allocation. It's too late for the direct drawing to avoid that, because the patch is waiting exactly for the moment when DOpus5 tries to draw the planar images with the blitter.

The pen allocations and releases are done by graphics.library. There is a reference counter for every shared pen that is increased by 1 for every color of an icon palette that is mapped to this pen. Only when all icons and other images have released their color mappings to a particular pen then its reference counter can go down back to zero which is the precondition to set the pen free again. It needs a call to IconControlA() or LayoutIconA() with a screen=NULL in order to release all pens of a screen or an icon. Or FreeDiskObject() will do that, too.

[Michael]

Originally Posted by PeterK

The pen allocations and releases are done by graphics.library. There is a reference counter for every shared pen that is increased by 1 for every color of an icon palette that is mapped to this pen. Only when all icons and other images have released their color mappings to a particular pen then its reference counter can go down back to zero which is the precondition to set the pen free again. It needs a call to IconControlA() or LayoutIconA() with a screen=NULL in order to release all pens of a screen or an icon. Or FreeDiskObject() will do that, too.

I know DO is a bit sad, but taking the above into account, can we call DO to release the pens when a window is closed or at some timed intervals ?
Or maybe have a manual DO menu option to do it.... Time to study docs and sources...