icon.library 46.4 test versions

[Michael]

Done some more experiments... No MemTrailer or other patches of this type, only debug tools running.

It was somewhat fun trying to get my system to run 3.1 with many things requiring much newer WB lib to function at all, even WB reaction prefs :-( Anyway, got the dusty WB disks and all the classic part required.

Now, the only problems I have spotted so far with the rom based workbench.library and v460 lib is WB in 8bit modes, for some reason in 8bit CGX all Gicons that were on screen become B&W/grey style (mainly disk icons) since refreshing any window with icons redraws them in proper colours. Plenty of free pens available, so we are not starving. But if we switch to 15/16/24 bits, colours are ok and pens are reserved correctly every time.
This side effect is not present with new WB lib, there any 8/16/24 mode works the same and correctly.

The second problem is DO with rom WB lib, that fails to switch screenmode, actually the change happens but something gets blocked and you have a working system but nothing on screen (mouse over grey screen)
However this behaviour happens with rom and v45 icon lib too. So I doubt it's icon lib fault.

And finally, is not v45.2 icon lib supposed to display 3.5 icons ? I think it did so before, now I get only black dots for all Gicons on my WB. While rom lib shows at least alternative 4c images. Again this is true for rom WB.lib.
With newer WB lib all icon libs behave differently. Also noticed that your lib keeps borders on for all icons with rom based WB libm and no borders for newer WB libs. Lot's of fun.

[PeterK]

Originally Posted by Michael

... for some reason in 8bit CGX all Gicons that were on screen become B&W/grey style (mainly disk icons) since refreshing any window with icons redraws them in proper colours. Plenty of free pens available, so we are not starving. But if we switch to 15/16/24 bits, colours are ok and pens are reserved correctly every time.

Not sure if I ever tested CGX on old WB, at least not the 8 bit modes. And I also have a little doubt that the 15-24 modes could work correctly, since they would need to run through both blitter patches, direct drawing and delayed image2. The color mapped selected images (dragged icons, Icon Info) should look broken or may even crash the system, do they? Could be avoided with NoDelayedImage2.

The second problem is DO with rom WB lib, that fails to switch screenmode, actually the change happens but something gets blocked and you have a working system but nothing on screen (mouse over grey screen)
However this behaviour happens with rom and v45 icon lib too. So I doubt it's icon lib fault.

And finally, is not v45.2 icon lib supposed to display 3.5 icons ? I think it did so before, now I get only black dots for all Gicons on my WB. While rom lib shows at least alternative 4c images.

None of the v45 icon libs has support for the old WB calls to GetIcon() or PutIcon(). Same with v45.2. These calls will fail and maybe the old WB then tries again with GetDiskObject() and PutDiskObject()? I don't know, but in that case it would get the planar images only (black dots or similar). The ROM lib will probably display the internal 4c images for unknown or unreadable (e.g. PNG) icons.

The problem with the DOpus5 screenmode switching is next I will care about. Today I already noticed that DOpus5 doesn't like to see icon.library allocating new pens again after a screenmode change. Now I have to find out why exactly.

Also noticed that your lib keeps borders on for all icons with rom based WB lib and no borders for newer WB libs. Lot's of fun.

The default for old-style icons is borders ON and for color icons OFF. You can force that with PlanarFrames1/2/3 or if you prefer use AllFramesOff.

Added AllFramesOn1/2/3 and updated AllFramesOff (yesterday):

AllFramesOff informs the Workbench v44+ now about the invisible frame size of 1 pixel which is important for the correct image position when direct drawing is used on gfx cards. All icons will become frameless. AllFramesOn1/2/3 is also for systems with workbench.library v44+ only and sets the frame size to 1-3 pixels. If you call these commands on a running system it needs a WB Reset from the tools menu to update the frames. But some color icons may never get any frames because they have an internal "Frameless" flag set which can only be changed with OS 3.9 IconEdit. In case you have called PlanarFrames1/2/3 before, all color icons will always remain frameless, even after a subsequent call of AllFramesOn1/2/3 because OS 3.9 needs that. These new commands (except PlanarFrames1/2/3) are not required for OS 3.9 which has the Prefs/Workbench program for the same purpose.

[Michael]

Small update to my findings....

If we first run WB via LoadWB and then run DO with LoadDB on top of WB then on screenmode refresh all images for Gicons are missing, but MWB icons are ok.
If DO is run as App from WB on top of WB then icons are displayed on screenmode changes, in full colour on 16/14 bit modes and in grey/false colour in 8bit or less.

So yes, there is still some work to do ;-) But no crashes or hits.

[PeterK]

Update to icon.library 46.4.461:

Fixed the DOpus5 problems with the screenmode switching. DOpus5 is calling LayoutIconA() in a wrong way or at the wrong time and releasepens was crashing then, probably because the old screen was already gone. DOpus5 should better use IconControlA() for releasing the pens and the remapping. Now releasepens is not done anymore and that seems to work.

@Michael
Thanks for all the detailed information. All these smaller discrepancies are on my ToDo list now. But I'm glad that at least the worst crashes are fixed.

[Retrofan]

Wonderful Peter. It works with a drawer opened even. As long as you don't have AmiDock working it will change the screen mode.

It's a great improvement.

[PeterK]

Hi Retrofan,

so what's new in your statement now compared to the previous one?
Where is the great improvement?

Originally Posted by Retrofan

Peter I've been trying with DOpus5 and it works perfect changing screen modes. It works also while using WBDock or BDSlide by Thomas Rapp.

When it doesn't work is when you are using AmiDock (the one of OS3.9).

[Retrofan]

The new statement is that I didn't tell you that before (that it's a great improvement)

I mean that I know that when you work hard to make something, it uses to be better that post than several ones with "Yes, it works.".

[PeterK]

The great improvement for me is that it works now without MemTrailer on my test configuration (DOpus5 on OS 3.1). DOpus5 is still crashing during screenmode changes on my old AmiKit X beta, but the latter is very unstable. No idea how good or bad the commercial release is compared to the buggy beta version. As far as I can remember the old 8.5 release did change screenmodes without crashes as long as you disabled the old AmiStart 0.66 in XChange before trying to switch to a new screen.

[Retrofan]

I can't tell about AmiKit X, sorry, I only have time to try AKReal 9; you should try it too . Email me if you need whatever. Anyway it was very tricky to have AmiStart working from 16 colors on as it wasn't in fact tried to work with that.

[Michael]

Not happy with 46.4.461 not releasing pens during normal use (open/close window with many icons like prefs) since I loose almost all free pens then and they are not in use.
Preferring previous version for regular use, since scenmode changes are less important, and they work on my setup, and small colour glitches with icons when switching to 8bit mode are not a big issue here.

Actually with 46.4.461 the pens still get release during screenmode changes under DO in WBR mode, so I don't understand why they are locked in normal use.

[PeterK]

The problem is how to distinguish a normal pen release from one made for a screenmode switch. I cannot accept instability or even crashes. Maybe it could still work if I would allow DOpus5 to call releasepens on the actual screen only? Btw, what do you need the free pens for?

[Michael]

Free pens are required to run whatever needs pens allocated and when you are out of them you have a problem. Currently I have 180 free pens for regular use, if I open prefs I am left with 40, if open something else, then this number quickly goes to zero and does not return. With previous version closing the not needed windows gave everything back to the system. And I had peace in my mind.

[PeterK]

Please tell the applications which are not able to share the colors of the existing screen palette when it runs out of free pens. Ok, your apps may get slightly better colors if they still can obtain a few new pens but they won't get a problem if there are no free pens left. They always get the closest colors that are available in the screens palette. Show me two screenshots comparing 460 and 461 to see how big the difference really is.

I've already tried to find a criteria to distinguish between the good and the bad LayoutIcon() calls from DOpus5, but no luck, although I didn't give up yet.

I have peace in my mind if nothing is crashing or throwing Enforcer hits.

[Amiga68k]

Perhaps something to add to the free pens discussion.

I have a WB RTG environment (P96, 32bit, 1024x768) and use the following two utilities on the WB screen:

- YAM (default set)
- DOpus4

Where things go wrong colourwise is when doing the following:

1. Startup DOpus4
2. Iconify DOpus4 (iconify to small window)
3. Startup YAM
4. Uniconify DOpus4

See example pictures of what the colours look like in DOpus4.

When I iconify DOpus4 again, quit YAM and uniconify DOpus4, colours are correct. Colours stay incorrect when only iconifying YAM.

Please let me know if I'm looking in the right direction. Perhaps this is related to something else completely (MUI, DOpus4, YAM, WB, whatever).

It just smells like 'free pens'

*Edit, I thought it was the Mason icon set, but it's actually the default YAM 2.10 theme)

[PeterK]

Thanks for explaining your color problem with DOpus 4, Amiga68k.

I have the same behaviour on my OS 3.9 system with P96, 32 bit screen for many years already. DOpus 4 sometimes shows slighly different colors, although the icons are displayed in direct drawing mode and thus there are usually enough free pens left.

You can see the number of used and remaining pens in Scout's window list in the Workbench screen info. It may also help to release more pens by doing a WB Reset from the tools menu. I've no idea why DOpus 4 sometimes has these problems to find/get better colors/pens.

Maybe DOpus calls ObtainBestPenA() with a too low precision level. There are four possible qualities: Exact, Image, Icon and GUI or in other words Very Good, Good, Medium and Bad. If DOpus uses precision GUI (I don't know) it will have problems to get new pens if only a few of them are remaining. The price for a free pen depends on how many are left. The price is the color error that has to be accepted by sharing pens.

[Amiga68k]

Originally Posted by PeterK

I have the same behaviour on my OS 3.9 system with P96, 32 bit screen for many years already. DOpus 4 sometimes shows slighly different colors, although the icons are displayed in direct drawing mode and thus there are usually enough free pens left.

You can see the number of used and remaining pens in Scout's window list in the Workbench screen info. It may also help to release more pens by doing a WB Reset from the tools menu. I've no idea why DOpus 4 sometimes has these problems to find/get better colors/pens.

Yes, but... there's always a but

The problem is not present when using the 'old' v45.1 of the icon.library

Figures when using v46.4.461:
DOpus4 started: 256 shareable, 72 used, 184 free
DOpus4 iconified, YAM started: 256 shareable, 209 used, 47 free
DOpus4 uniconified, YAM still running (colour issue): 256 shareable, 210 used, 46 free
Quitting YAM and uniconifying DOpus4 again causes the figures to jump to the first values again (72/184)

Figures when using v45.1:
DOpus4 started: 256 shareable, 129 used, 127 free
DOpus4 iconified, YAM started: 256 shareable, 169 used, 87 free
DOpus4 uniconified, YAM still running (no colour issue): 256 shareable, 175 used, 81 free
Quitting YAM and uniconifying DOpus4 again causes the figures to jump to the first values again (129/127)

Maybe DOpus calls ObtainBestPenA() with a too low precision level. There are four possible qualities: Exact, Image, Icon and GUI or in other words Very Good, Good, Medium and Bad. If DOpus uses precision GUI (I don't know) it will have problems to get new pens if only a few of them are remaining. The price for a free pen depends on how many are left. The price is the color error that has to be accepted by sharing pens.

Not sure what to think of the figures. A quick glance shows that DOpus4 takes more free pens with the old icon.library (6 vs. 1)... and YAM uses less pens (209 vs. 169).

*Edit: Setting SYS:Prefs/Workbench to Icons Quality: Bad causes YAM to 'take' fewer pens it seems. When DOpus4 is uniconified afterwards, the result is 'slightly' better. Still not the same as with the old icon.library though.

[Michael]

It is really tough to find a dead end situation with colours, besides I have a very nice set of locked colours by default that keeps the spectrum. It is much tougher for people with 16-64 colour settings.
Anyway, when we are short on pen colours some programs are washed out (eg. EaglePlayer Genies and other similar eye candy)
Some clever tools start to open on custom screen when they run out of free pens on public screen.
eg. even system pointer prefs and of course icon editors, palette requesters are dead when they do not have a dynamic pen to play with. And then there are new icons you open when you closed previous drawers and they don't get the best pallet they could have got as they did before.

[PeterK]

You can not compare the number of used or free pens between icon.library v45 and v46. Both have totally different algorithms for the color mapping and pen allocation. It's impossible to get the optimal colors for everything. I've tried that more than a thousand times 10 years ago, but there is no best solution! It's always a compromise. As soon as some images are looking better others get worse.

Play with the color quality settings in WBPattern and Workbench preferences. Don't think that the highest quality gives the best results. No, it just allocates the pens faster until none are left for other images. If you set the icon quality to "Bad" on WB 3.9 then my library uses the "FastColors" option. You can also play with my old IconBeFast 1.16 which patches ObtainBestPenA() and uses an optional value between 0 and 255 as an adjustment for the quality level. But IconBeFast is not supported anymore and I have removed it from Aminet some months ago.

[Amiga68k]

Thanks for the explanation and the lesson in pens PeterK. I didn't know before that WB is actually quite limited then (when it comes to the amount of available pens that is...). Sure, there are millions to choose from I guess, but having only 256 'shareable'... interesting.

Your new icon.library is brilliant though and there are multiple workarounds for the YAM/DOpus combo, so no worries there.

Greetings

[daxb]

Originally Posted by Amiga68k

I didn't know before that WB is actually quite limited then (when it comes to the amount of available pens that is...). Sure, there are millions to choose from I guess, but having only 256 'shareable'... interesting.

Without RTG and AGA the max screen depth is 8 bit = 256 colors. So max 256 colors to share between WB, programs and everything else who allocate pens. First comes first. Steeling pens from other tasks won't be a good idea.

With RTG you can have 16 or 24 bit screens what should deliver enough pens for everything.