icon.library 46.4 test versions

[PeterK]

Thanks a lot Amiga68k!

So, the H bit can be used to avoid "resident" commands. Nice, but both is meaningless for fast computers with SSDs and big caches.

[PeterK]

In case that somebody still wants to use my library with OS 3.2, you will need at least a v47 version like TC020 now, which already supports the new DefIcons, too.

However, you can still downgrade TC020 with my option "ConvertTrueColor" if you prefer to create OS 3.5 ColorIcons only.

My old v46 versions are not accepted anymore by OS 3.2 and they also have no support for the new file type identification features of the DefIcons tool.

[Cobra]

Hi PeterK, I downloaded the latest icon.library 46.4 from Aminet and been testing it on an A1200 running AmigaOS3.1, using a 16-color workbench. It works beautifully, but I noticed a strange issue when using it together with workbench.library 45.134 (also getting same result with 45.136 and 45.137) that when moving multiple newicons, all moving icons are corrupted except the first one being dragged. Moving all the icons individually shows no corruption on any of them, so this only happens when moving more than one newicon. Also, if I move multiple MagicWB icons, there is no corruption. Here is a video showing the issue:

https://photos.app.goo.gl/mw19zELDjVQznehW6

I tried both 68020 and TC020 versions of icon.library and seeing the same effect. It's worth noting that with the original workbench.library I'm not seeing the issue, so maybe it's just a bug in the workbench.library 45.13x versions? Have you seen this problem?

I'm also not seeing the issue when using Directory Opus Magellan in "Workbench:Use" mode, dragging multiple newicons works well in that cae. However with Opus Magellan I have another problem that MagicWB icons do not appear in the correct colours, even though the palette should be identical (I'm using FullPalette to manage it), so I wonder if Directory Opus Magellan goes through icon.library at all?

[TuKo]

On my side, I reverted back to workbench.library 45.132 and ran away from all Cosmos hacks which produced such bad side-effects.

[PeterK]

Hello Cobra,

as TuKo already mentioned the workbench.libraries 45.133-45.138 are all known to have new bugs. I also made a note for some of them about a dragging problem, others have a deleting issue, etc.

You can either use the original 45.127 which has some other older bugs, or fix it with my patch to get 45.132 which you can find in the bonus drawer of my IconLib package. The new WB 45.194 of OS 3.1.4 is also ok.

Usually, the MWB colors should be correct under DOpus5 if you set and lock the pens 0-7 and the last four colors of the palette with FPPrefs. On WB 3.0/3.1 there is a problem with the NewIcons patch in case that you want to have transparent backgrounds for NewIcons and ColorIcons. Then the background may shine through MWB and old icons for all pixels with color 0.

If only some of the MWB icons appear with wrong colors, that's probably because they use 8 bitplanes instead of 3 and the last four colors of the palette are not correct. My library has a new option "Reduce8PlanesTo3" now. Try that.

Unfortunately, there are always many other possible reasons why something could go wrong, but at the moment I don't have my OS 3.1 system ready for tests, since I accidentally deleted my WinUAE drawer some months ago with all the config files.

DOpus5 uses the blitter routines of graphics.library directly instead of calling DrawIconState() in icon.library. Therefore icon.library has to patch the blitter functions, and these patches may interfere with similar patches from other tools.

[Cobra]

Thanks Tuko and PeterK, I tested wth some other versions of workbench.library from amiga.foul.fr, including 45.127, 45.131 and 45.132 and I still have the same problem with all of them. It turns out if I disable FBlit in the startup-sequence, then the problem goes away. So it seems that somehow a combination of FBlit and these newer versions of workbench.library are triggering the issue (it seems to work fine with the original workbench library that's part of 3.1). And yes I did copy the FBlit.config file that's supplied with icon.library to ENVARC:.

About Opus5 MacigWB colors, I still don't fully understand what's happening. I have a 16-color screen with FullPalette. The first 8 colors (0-7) are standard MacigWB colors, the other 8 colors (248-255) are used for NewIcons. With normal Workbench, all MagicWB icons are showing correctly and using the first 8 colors, but when I load Opus5.82 Magellan with Use:Workbench option and close/reopen the windows so the icons are reloaded, all MagicWB icons I have (such as all icons of the standard MUI 3.8) seem to be using pens 252-255 where they should be using pens 4-7 to get the correct colours. Here's an image showing the palette and how the MagicWB icons look:

https://photos.app.goo.gl/n6AoduNy613E1gPR9

This is only an issue with Opus5.82, all the MagicWB icons show with the correct colors in the normal Workbench. I tried to run Reduce8PlanesTo3 but it didn't make any difference, I tried running from Shell before or after I started Opus5, as well as from the startup-sequence before LoadWB, but still getting the incorrect colors for MagicWB icons :/

Edit: I just solved the Opus5 icon color issue by disabling 'Remap Icon Images' under Environment->Icon Settings. Doh!

[TuKo]

Regarding FBlit, Peter was smart enough to provide good working config files in IconLib package :
ThirdParty/FBlit/FBlit.cfg_WB_3.1
ThirdParty/FBlit/FBlit.cfg_WB_3.1.4+

This might save hours of headache

[PeterK]

The FBlit issue with corrupted icons is probably caused by using the wrong FBlit.cfg file. You need the FBlit.cfg for WB 3.1.4+ if you use a workbench.library v44 or higher. It doesn't matter that the rest of your system is still OS 3.1. The version of workbench.library is the important difference for FBlit.

Great, that you could solve the DOpus5 problem with the MWB colors. Yes, I already knew that "Remap Icon Images" setting and this issue, but didn't touch it anymore for many years and forgot about it again.

[Cobra]

Thanks TuKo and PeterK, you were right! I incorrectly copied the FBlit config file for 3.1 instead of 3.1.4. Copying the 3.1.4 in solved the corruption issues during icon dragging!

So now I now have bug-free icon dragging in Workbench and I also get correct colors in Opus 5.82 I'm noticing that icon loading is significantly slower in Opus 5 though. Is there a way to make it as fast (or close to as fast) in Opus5 as it is with workbench.library v45.1xx? I tried adding DOnoColorMappng in the startup-sequence as suggested in the icon.lib readme but this made no difference as I think this only applies to using RTG modes, and not the 16-color mode I'm currently using. I also tried with/without the 'Icon caching' option in Opus5 and that also didn't seem to matter. I love using Opus5 Magellan in place of workbench but the difference in icon loading speed is huge, I made a video that shows this:

https://photos.app.goo.gl/TcpBdVqR997S1CMe7

[PeterK]

Yes indeed, DOpus5 is significantly slower on native Amiga screens (needs more than twice as long as WB) and my option DOnoColorMapping only helps on RTG to make it faster.

It seems to be very difficult to patch the blitter call of DOpus5 for native screenmodes and add a feature like my delayed color mapping for the second icon images, because I would have to deal with too many different configurations in the same patch, and that could make everything slower.

Hmm, just watched your video, and it looks not as slow as I expected it to be.

But you can accelerate both a bit more, WB and DOPus5, by using my option "FastColors", although the benefit on a 16 color screen is less than with 256 colors.

Update: Another DOpus5 setting that you can use to make icon rendering faster is "Borderless Icons Are Fully Transparent", but with the drawback that the background (wallpaper) shines through for all pixels with color 0 on native screens, the same effect as with the NewIcons patch on WB. This is no big problem if you just have a gray background.

[PeterK]

Update to icon.library 46.4.544 and 51.4.544:

 OS 3.2 needs at least an icon.library v47 now.
 Thus, only TC020, FastWB and HAM6/8 will work.
 They can be used instead of my 68020 version.

 The new Workbench of 3.2 should be more efficient
 and faster now by avoiding unecessary refreshes,
 but I don't own the new OS and couldn't test it.
 I would expect that my FastWB version won't bring
 any speed improvements on 3.2 compared to TC020.

 All the TrueColor versions are able to load OS4
 and PNG icons 30-70% faster now on native screens
 with WB v44+ or Wanderer, except old WB or DOpus5.

 In case that you still prefer to save OS4 and PNG
 icons as ColorIcons, then use "ConvertTrueColor".

 The new 3.2 file type identification of DefIcons
 is only supported by my v51 libraries like TC020.
 I've no intentions to upgrade the 680x0 versions.

 The DefIcons file type identification should work
 now even for pictures if Eastern is also installed.
 A small CLI test program FileType is supplied, too.

 Removed the IconUpScaling, IconDownScaling and
 the GrayScaling support from TrueColor versions. 

 Important restrictions:

 It's not allowed to distribute or install the
 TrueColor versions of this icon.library with
 or on AmiKit X or AmiKit XE or in any software
 collection for more than 10 Euro. This are all
 the v51 versions, LD020 and the Aros version.
 They will switch to a low quality mode after
 a while and it's not recommended to use them
 on AmiKit X or XE, which are not supported !!

 But you can still use the 68000 or the 68020
 version or any icon.library of older releases
 up to 46.4.538 without any restrictions.

[Cobra]

Originally Posted by PeterK

Yes indeed, DOpus5 is significantly slower on native Amiga screens (needs more than twice as long as WB) and my option DOnoColorMapping only helps on RTG to make it faster.

It seems to be very difficult to patch the blitter call of DOpus5 for native screenmodes and add a feature like my delayed color mapping for the second icon images, because I would have to deal with too many different configurations in the same patch, and that could make everything slower.

Hmm, just watched your video, and it looks not as slow as I expected it to be.

But you can accelerate both a bit more, WB and DOPus5, by using my option "FastColors", although the benefit on a 16 color screen is less than with 256 colors.

Update: Another DOpus5 setting that you can use to make icon rendering faster is "Borderless Icons Are Fully Transparent", but with the drawback that the background (wallpaper) shines through for all pixels with color 0 on native screens, the same effect as with the NewIcons patch on WB. This is no big problem if you just have a gray background.

I tried the "Borderless Icons are fully transparent" option, and this resulted in a significant speed increase and is almost as fast as with workbench.library 45.1xx. I captured the speed with and without this option in a video here if you're interested: https://photos.app.goo.gl/M2RUn3gvP94suQP97

However with this option I do have the problem of icons becoming "see-through" over the background, which is mainly an issue with MagicWB icons ending up looking funny so I don't think I'll be able to leave that enabled. Another thing I'm noticing with Opus5 icon drawing is that there is a brief flash of the background of newicons as they are getting loaded, you can see it in the video I made if you watch carefully, it's there both with and without the "fully transparent" option. It's possible that I would need to use different FBlit settings to make icon drawing more efficient with Opus5.

I agree that the icon loading speed is quite good in both cases, although Opus5 Magellan does take roughly twice as long to load the icons, it's still quite fast on my Vampire V1200 setup. However now that I've seen just how lightning fast it is with workbench.library 45.1xx, it's hard to settle for the Opus5 icon loading speeds, as much as I love using Opus5 I wish the Opus5 sources could be made available to allow icon loading to be optimized as it was done in workbench.library.

All in all I have to say that icon loading speed is very, very impressive with icon.library 46.4 and workbench.library 45.1xx on a Vampire-accelerated A1200 and is basically comparable to what you get with a modern 600+MHz PPC-based system running AmigaOS4, so hats off to everyone involved in getting it as good as it is

[AMIGASYSTEM]

Hi Peter, thanks for the update (at the moment Aminet doesn't work), for AROS and AfA OS are there any improvements ? the new version on AROS 68k the icons are perfect.

Have you seen my video with the themes I created, they work both on AROS 68k and AROs x86, ibelle the icons also on WBDock2 by the good Thomas !


[ Show youtube player ]

[pipper]

[mention]Cobra [/mention] the source to Dopus5 is open and available on Sourceforge, or my fork on GitHub if you prefer Git https://github.com/mheyer32/dopus5allamigas
I’d be glad if someone would carry the torch a bit further :-)

[Cobra]

Originally Posted by pipper

[mention]Cobra [/mention] the source to Dopus5 is open and available on Sourceforge, or my fork on GitHub if you prefer Git https://github.com/mheyer32/dopus5allamigas
I’d be glad if someone would carry the torch a bit further :-)

I'm a little embarrassed, it just shows how long I've been away from the Amiga scene... I just had a quick look at the sources, I guess the code responsible for loading and drawing the icons is in Modules/icon.c. I tried 5.91 but it just hangs when I try to run it on my system, so I copied the icon module from 5.91 to 5.82 and then ran 5.82 which worked, but the icon loading speed did not change. What sources were the newer workbench.library versions created from? Maybe worth checking what Opus5's icon module does differently.

[PeterK]

Originally Posted by Cobra

I tried the "Borderless Icons are fully transparent" option, and this resulted in a significant speed increase ...
... I have the problem of icons becoming "see-through" over the background, which is mainly an issue with MagicWB icons ending up looking funny ...

Yes I know that, but I don't care much about a few funny MWB icons on my system. The advantage of "Borderless Icons are fully transparent" on RTG screens is that OS4, PNG and ColorIcons are not affected, because they are drawn directly on the gfx-card, not using the blitter.

Another thing I'm noticing with Opus5 icon drawing is that there is a brief flash of the background of newicons as they are getting loaded ...

That's caused by a strange method how DOpus5 is loading and refreshing icons in a window, and I can't fix it. DOpus5 is drawing every icon twice when you open a window. I already tried to suppress one of these drawings when I wrote my FastWB version, but then I noticed that some icons always disappeared when I tried to scroll or resize the windows.

I wish the Opus5 sources could be made available to allow icon loading to be optimized as it was done in workbench.library.

Yes, I have that source code too, but I don't like programming in C and it's also a huge project that would take a long time to understand all the code and recompile it correctly to make some optimizations. I've only disassembled some parts and fixed the custom icon dragging routines in place without recompiling anything (it's in my bonus drawer).

All in all I have to say that icon loading speed is very, very impressive with icon.library 46.4 and workbench.library 45.1xx on a Vampire-accelerated A1200

But the Vampire has RTG. So I hope you are using my TC020 or FastWB version and a TrueColor screenmode on that system. Not just 16 colors!

PS. I would not recommend to install DOpus 5.9x. It has a few new bugs compared to 5.82/5.83 and my icon.library is adapted to 5.8x.

[PeterK]

Originally Posted by AMIGASYSTEM

Hi Peter, thanks for the update (at the moment Aminet doesn't work), for AROS and AfA OS are there any improvements ? the new version on AROS 68k the icons are perfect.

The speed improvements are only on 8-bit and native Amiga screens. I didn't test anything with AfA_OS yet, but usually AfA switches back to my library functions for native screens, so in that case it might also be faster now. On Aros 68k with Wanderer 8-bit or native screens should be faster, too. Nothing has changed for RTG modes.

[ Show youtube player ]

Funny bouncing icons! Nice that the YT player has a slider for fast forward streaming through all your themes.

[Cobra]

PeterK: I think that Modules/icon.c is all that needs to be optimized in DOpus5.82, so it doesn't require building the entire project, only the icon module I think.

Yes V1200 has RTG, but I don't have it set up yet (waiting for some cables to arrive) and in the meantime I'm being nostalgic with a 16-color workbench And I guess truecolor icons will not load as fast as the newicon set but will see!

[AMIGASYSTEM]

Hi Peter, on AROS 68k I deleted defIcon OS3 and restored the native AROS 68k/x86 system.

These AROS systems don't have and don't use Deficon, they natively recognize files through Descriptors (Datatypes).

Lately I became a developer and created some descriptors so that all formats are supported by AROS (LHA, LZH, LZX, RAR, TAR, TAR.GZ, TGZ, ZIP, TAR.BZ2).

Now the problem is that the AROS Icon.library works fine (see screenshot) and your Icon.library does not find the Def Icons in the ENV

I tried the string you recommended this:
Copy >NIL: "ENVARC:" "ENV:" ALL NOPRO NOREQ ; PAT "~(def_#?.info)"

Also tried "Assign Add ENV: ENVARC:", but it doesn't seem to work

Strange thing is that the def_RAM.info is found, if I use DefIcon everything works well again Any IDEAS?

[PeterK]

Hi Carlo,

I guess the reason for this problem is that Aros 68k doesn't create a hook function for the GlobalIdentifyHook of icon.library or it is not compatible with the OS 3.5+ standard interface. I have no idea how exactly Aros is doing this with the datatype system.

The icon.library can find the basic deficon types (disk, drawer, tool, project, trashcan) without the DefIcons tool, and also all deficons by name like def_ram.info for a string "ram", def_DF0.info for "DF0" etc, but it needs the DefIcons tool to identify all other unknown files.

In addition, my library has a special handling for the Ram Disk icon and will always synchronize it with ENVARC:sys/defRAM.info and also in ENV:.

I've just uploaded another update to Aminet, which should appear tomorrow with a brand new IconLib.guide and IconLib.htlm manual in English and German, and a few bug fixes, of course.