icon.library 46.4 test versions

[AMIGASYSTEM]

Tried MemTrailer and many other utilities and none solve !

[PeterK]

I've installed the latest version of MUI5 now, and it seems that it was improved a lot since I tried it last year. Some files are much smaller now than before, like the MUI preferences program, and the latest MUI5 gives a much better impression than older versions, so I will test it a little longer.

PatchASL is started with run after IPrefs in my startup-sequence and I've disabled other patches like ASLtoRT. Don't start PatchASL to early, it won't work correctly or not at all.

I didn't get any Enforcer hits, freezes or crashes here, but I have no really large collection of pictures, just maybe 20-25 in a directory. Also no problems when I enable "#?.info" files in the requester and than load huge collections of icons, everything works.

First I tried PatchASL on my Workbench 3.9+3.1.4 and then also with AfA_OS, and the latter works too as long as "RemLib >NIL: icon.library" is called at the end of my startup-sequence. Btw, AfA_OS_Loader is started before IPrefs, PatchASL after IPrefs and RemLib just before EndCLI.

With icon_lib.exe only AfA crashes as soon as I open the ASL requester or gets Enforcer hits from icon_lib.exe.

Update: I've forgotten to tell you that I have a "Wait 2" before RemLib, which is required to wait for Eastern, or my icon.library and Eastern may not work reliable together on AfA_OS.

Set AfA ON
If $AfA EQ ON
   MoreLibSpace >NIL: REBOOT
EndIf   
...
...
If $AfA EQ ON
   AfA_OS_Loader >NIL:
Else
   Run >NIL: VisualPrefs
EndIf   
Wait 1
IPrefs
FPPrefs
ConClip
Run >NIL: PatchASL

...
If $AfA EQ ON
   Wait 2 ; wait for Eastern
   RemLib >NIL: icon.library
   KeepPlanarImages
EndIf
EndCli

[AMIGASYSTEM]

Originally Posted by PeterK

I

PatchASL is started with run after IPrefs in my startup-sequence and I've disabled other patches like ASLtoRT. Don't start PatchASL to early, it won't work correctly or not at all.

MUI 5 from setup automatically adds the command (RUN <>NIL: MUI:PatchASL) in the user-startup "after" MUI assignments.

If PatchASL is run before Assign MUI does not work ?

AfA_OS, and the latter works too as long as "RemLib >NIL: icon.library" is called at the end of my startup-sequence. Btw, AfA_OS_Loader is started before IPrefs, PatchASL after IPrefs and RemLib just before EndCLI.

Yes I have these settings the only difference that "RemLib" is in the first line of the user-startup

With icon_lib.exe only AfA crashes as soon as I open the ASL requester or gets Enforcer hits from icon_lib.exe.

Me with icon_lib.exe" I have no problem the GUI opens quickly and also the thumbnails images are fast.


Tried your setting (brought assign MUI before the PatchASL comado) but the crash is always there, to find the problem you need a lot of images "quality" and click while showing images.

[PeterK]

Ok, keep your RemLib config on AfA_OS as long as that works for you, I just wanted to show you what my settings are, which doesn't mean that they must be the better choice.

And no, I don't have any user-startup, nor do I like to use Installer scripts on my system. In very rare cases I first let them run in demo mode to see in the log file what they would try to overwrite before I let them install anything.

Last night I've also seen that PatchASL and MUI5 are doing all the image decoding and scaling themselves, even with icon.library v45 it works. All cybergraphics.library functions are patched by the mount command(seems that was a wrong info of SegTracker). But they still have color problems with OS4 icons on 8 bit or planar screens. Only a few icon images are coming from icon.library and are probably captured and downscaled on their way to graphics card, but I didn't analyze that yet.

So, if there are problems with the image decoding that lead to freezes or crashes, you could also try out the original icon.library, although I think it looks more like a PatchASL issue than an icon.library bug. Sorry, I don't want to download huge picture collections for making experiments. But on my old HDD in the cellar there should be a lot of them stored. Maybe a good occasion to make a backup of my SSDs again.

Just seen at your amiganews.it page: Are you using TLSFMem? Then remove it, it was never a safe memory management replacement.
Edit: Oh, it's a new version (?), just released today on Aminet (again ?), didn't notice that before, but v1.9 was already used inofficially by Cosmos years ago, I think. Nothing I would recommend to use. Update: 1.6 on Aminet is an old version from Chris Hodges, nothing new or fixed.

[AMIGASYSTEM]

Originally Posted by PeterK

And no, I don't have any user-startup, nor do I like to use Installer scripts on my system. In very rare cases I first let them run in demo mode to see in the log file what they would try to overwrite before I let them install anything.

Even I never do automatic installations I install everything manually, even on Windows I use almost all Portable or Stand-alone programs, when it is possible to transform even the installed ones into Stand-alone.

I use the user-startup because I like to keep the startup-sequence as standard as possible and add only what is needed.

I have never used TLSFMem, I just did the review and I think that the problem is caused by PatchASL maybe in a next version the problem is fixed.

In any case if you don't do the preview PatchASL works very well and it's very convenient, the only flaw is that you can't store size and GUI setting.

[PeterK]

Update to icon.library 46.4.533:

The data structure for the palette mapped and TC images has been cleaned up, expanded by 4 bytes and optimized. Thus, the limit of maximal 248 CLUT colors for images, which existed before to store the 2 pointers of TCbuf2 and a freelist there, could be eleminated. - TrueColor icons with only 1 image are a bit faster now.

I've made a new experimental "FastWB" version to achieve a faster and more responsive TrueColor icon dragging on Workbench 3.1.4/3.5/3.9 for slower Amigas. This is not a 100 % perfect solution, because it still can happen that some parts of the window where you select the icons are not refreshed after the dragging, but that's not a big problem, since you can still update the window from the WB menu. My fix already tries to take care for any window switching, scrolling, resizing and also has a timeout of about 1 second after the last icon movement in order to avoid a later graphical damage from menus or requesters opening suddenly over the active window. Try it out and report any issues or enjoy the speed-up. It's best used together with my option "HoldTCbuffer1".

The Aros version uses 2 source and 1 target buffer now for the Alpha Channel based merging of foreground and background colors, and hence can re-use the TCbuffers.

DOpus5 can also benefit from the acceleration of the TCbuffer2 and the UnderCover mode, the late unpacking of the second image, but only when the DOnoColorMapping option and the custom dragging routines are enabled. Unfortunately, the custom dragging routines of DOpus5 have a big memory leak and the image masking is simple.

[James]

Originally Posted by PeterK

Update to icon.library 46.4.533:

Thanks! Not spotted any problems yet.

Originally Posted by James

Also noticed when grabbing example image to Ram: on OS3.5, the filename was too long and it was treated as an icon:

Just noticed that the OS3.5BB2 installer doesn't install the ROM update.
That means my OS3.5 install didn't have the ram-handler (44.21) or console.device (44.6) updates from BB2.
Happy with AmberRAM now so can't be bothered to switch back.

[PeterK]

Originally Posted by James

Thanks! Not spotted any problems yet.

Ok, that's nice ... although ... I've seen some already, but won't tell how to reproduce them.

Also noticed when grabbing example image to Ram: on OS3.5, the filename was too long and it was treated as an icon:

Ah, that's an oldie! Should not happen anymore since I added a check last year which prevents an icon from overwriting its main file when both names get truncated by the filesystem. If it still occurs then you need the OS 3.1.4 icon.library or a filesystem which supports longer names as you did it.

Just noticed that the OS3.5BB2 installer doesn't install the ROM update.
That means my OS3.5 install didn't have the ram-handler (44.21) or console.device (44.6) updates from BB2.
Happy with AmberRAM now so can't be bothered to switch back.

Don't know much about OS 3.5, but I used the good old AmberRAM for many years, too. Now, I have some parts of OS 3.1.4 installed on my OS 3.9 system, including the new ram-handler.

[AMIGASYSTEM]

Originally Posted by PeterK

I have some parts of OS 3.1.4 installed on my OS 3.9 system, including the new ram-handler.

In my opinion this is not a good thing, the system applications, Prefs, Utility et..of OS 3.9 BB4 are more modern and functional (expandable GUI) and the "calaogs" of OS 3.9 are not compatible OS 3.1.4 uses the old "local" structure of OS 3.1.
I also found other conflicts on some libraries, now I don't remember well, probably with the next OS 3.2 it will be different

This is my OS 3.1.4.1 AfA OS (icons Dual-PNG)

[gulliver]

If you are on to emulation and eye candy you should better look for OS4.1FE. That one beats the crap out of 3.9 in every categoty and still has some solid features.

From a technical point of view 3.9 was plagued with serious mistakes. Catalogs is just one of them.

But it was good for it visual appearance and bundled third party apps.

[AMIGASYSTEM]

I also embellished my OS4.1 but underneath there is no OS3, there are Linux infiltrations that I never liked.
OS 3.9 is no longer updated but at the moment in my opinion it's more practical and more usable than OS 3.1.4 which as already said still has an old OS 3.1 look.

[fitzsteve]

Unless you have a monster processor the PPC emulation is still quite slow, everything runs much quicker from their 68k versions under OS3x. Furthermore you only benefit from the 3D Hardware compositioning on real hardware.

@AmigaSystem that's a really nice setup. Looks great.

[PeterK]

Originally Posted by PeterK:
I have some parts of OS 3.1.4 installed on my OS 3.9 system, including the new ram-handler.

Originally Posted by AMIGASYSTEM

In my opinion this is not a good thing, the system applications, Prefs, Utility et..of OS 3.9 BB4 are more modern and functional (expandable GUI) and the "calaogs" of OS 3.9 are not compatible OS 3.1.4 uses the old "local" structure of OS 3.1.
I also found other conflicts on some libraries, now I don't remember well, probably with the next OS 3.2 it will be different ...

... even more different again ...

Don't worry Carlo, I've checked every single component of 3.1.4 against the older ones from 3.9 before I installed only a few of them. It's in essence the new 3.1.4 Kickstart and some libraries like workbench and intuition, but not more than maybe 1/3 of all files yet. Just the best of both worlds!

I think that you already know that you can make catalog subdirs for OS 3.1 or 3.9 instead of "sys" and then patch the preferences or other files, in case you want to use old AND new prefs programs.

[AMIGASYSTEM]

Originally Posted by PeterK

I think that you already know that you can make catalog subdirs for OS 3.1 or 3.9 instead of "sys" and then patch the preferences or other files, in case you want to use old AND new prefs programs.

Yes I did initially and then "a soup" came out and I preferred to configure a clean OS 3.1.4 "without any native library substitutions" by adding only the missing libraries, your icon.library and the AfA OS extension.

[James]

Originally Posted by PeterK

Ah, that's an oldie! Should not happen anymore since I added a check last year which prevents an icon from overwriting its main file when both names get truncated by the filesystem. If it still occurs then you need the OS 3.1.4 icon.library or a filesystem which supports longer names as you did it.

Had a quick try with the OS3.1 and OS3.5BB2 ram-handlers and could no longer reproduce the problem.

[PeterK]

Update to icon.library 46.4.534 (TC020, LD020 and FastWB only):

This update comes with a fix for the big memory loss in the Custom Dragging Routines of Dopus 5.82 on P96 and a better transparency masking for the icon images when my option(s) DOnoColorMapping and HoldTCbuffer1 are activated. The DOpus5 patch of AfA_OS for Eastern and DefIcons made by Bernd Roesch can still be used with my fixed Dopus 5.83, since it's not a new C-compilation. The bug in the Custom Dragging Routines was the usage of the number of pixels per line for "Width" in the VSprite structure of AddBob() instead of "Words per row", and without any RemBob() later. I'm using only AddVSprite() and RemVSprite() now and that seems to work correctly.

My library also tries to improve the poor quality of the Dopus masking based on the background color by using a higher Alpha value of 60 or 75 to switch to 100% transparency already when my option(s) DOnoColorMapping and HoldTCbuffer1 are activated. This eliminates most parts of the gray borders. Using DOnoColorMapping together with the Custom Dragging and HoldTCbuffer1 can improve speed a lot now without losing quality or memory.

[PeterK]

Update to icon.library 46.4.535 (Aros, TC020, LD020, FastWB and Dopus 5.83 only):

The DOpus5 fix is also supported by the Aros 68k version now when my option DOnoColorMapping and the Custom Dragging Routines are enabled. Speed and quality of the masking can be further improved by using HoldTCbuffer1, which is a toggling On/Off switch. The fixed Dopus 5.83 has not changed since the previous release. Replace your DirectoryOpus file if you want to start it by LoadWB. And I've added a check for the main DOpus5 program task in the icon.library for icon dragging and the image masking, because the icons directly on the Workbench are not handled by the dopus_lister task and they still had some gray borders before.

[apex]

No, just installed 533. :-)

[PeterK]

I hope you don't have to burn a new Kickstart Eprom for every new version. Updating software is a never ending story ...

[pcotter]

Hi Peter
I have been using your Aros library since you introduced support for it. The feature of putting imgdata to Fast surely is a great addition.

Im confused about the Custom Dragging Routines. Do they need to be enabled on RTG? I ask because on all my amigas i use Dopus i always disabled this option when using RTG. On Aros or Aos.

Disabeling Custom Dragging Routines also avoids the memory loss bug? That is using when Dopus 5.82.

Anyways, im using now your dopus fix/libs on aros and Aos and so far everything seems to be running ok. Will let you know if i find anything odd.
Once again thank you for keeping developing this amazing library.