icon.library 46.4 test versions

[ozymandias]

Thanks to all! Already tested both classicwb with scalos and icon. Library and noticed that chipmem is always used with scalos. Only wb can use fastmem exclusively.

[Bloodwych]

Originally Posted by ozymandias

Thanks to all! Already tested both classicwb with scalos and icon. Library and noticed that chipmem is always used with scalos. Only wb can use fastmem exclusively.

You have to install it correctly, along with FBlit settings being correct.

See the screenshots below, the first one - that's with Scalos driven ClassicWB ADVSP 16 colour wallpaper and opening up several drawers, in fact I opened up an extra System drawer compared to OS39 to allow for Amidock icons.

You can see how it compares to Workbench in the second picture, which is OS3.9 using the latest icon.library from PeterK (CyberbugFix disabled) and same wallpaper and 16 colour screenmode. Disabling AmiDock makes no difference to the Chipmem just the Fastmem and as I said this picture has one less drawer open!

Scalos actually looks to be doing a good job thanks to PeterKs pack.

[PeterK]

Thank you, Bloodwych !

Is there an adjusted FBlit.cfg installed on your WB 3.9 system?
http://eab.abime.net/showpost.php?p=...&postcount=815

Usually, the Workbench needs no additional ChipMem for the icons if the FBlit.cfg is correct.

[Bloodwych]

I'll check the FBlit settings, thanks PeterK.

Unlikely they are optimized like in that thread.

[Bloodwych]

I checked and FBlit is optimized - OS39 uses no extra Chipram for displaying and opening icons just as you said and the patches are setup as described. It just uses more by default compared to the ADVSP on a fresh boot (1870k vs 1900k).

The reason Scalos shows more Chipram is although it uses tiny amounts of Chipmem for displaying windows and icons in certain situations, it rarely goes down by much and even opening every window in the System folder (24 drawers inc C Libs Fonts Games Demos etc) it is still at 1870k from 1900k default.

[PeterK]

Thanks for the clarification, Bloodwych

[ozymandias]

I should be an idiot with Amiga. I applied all patch and script in ClassicWB30Icons.lha and FblitCfg suggested by PeterK but still high chipmem usage with Scalos. I use MagicWB 2.0 icons, converted with COndenseIcon to 3.5. Maybe these icons are more chipmem-consuming than those in ClassicWB-ADVSP (which consume a little chipmem)?

[NovaCoder]

It's very easy to get fixated with free CHIPRAM, I only have about 1.6 MB free on my A1200 and very rarely run into lack of CHIPRAM issues.

[PeterK]

Originally Posted by ozymandias

I applied all patch and script in ClassicWB30Icons.lha and FblitCfg suggested by PeterK but still high chipmem usage with Scalos. I use MagicWB 2.0 icons, converted with COndenseIcon to 3.5. Maybe these icons are more chipmem-consuming than those in ClassicWB-ADVSP (which consume a little chipmem)?

ClassicWB30Icons.lha was written as an add-on package for ClassicWB ADVSP v27 and it's obsolete now since Bloodwych has included all my changes in ClassicWB v28 already and maybe updated some files where necessary. And why are you converting MWB-icons into the OS 3.5 format? I can't see any benefit from doing that, but the icons will need more disk space and a longer time for decoding them back into the planar format. I'm not sure if they will also consume more ChipMem under Scalos 1.2d.

[Foul]

icon.library 46.4.340
FS-UAE 1200/060 KS/WB 3.9

Some icons are weird, don't know why :

Happen in all mode 8/16/24 Bits RTG or not.



Startup-sequence attached and some "weirds" icons

[mfilos]

Do you mean the gray'ed icons which probably means the files DON'T have any icons?

[PeterK]

Originally Posted by Foul

icon.library 46.4.340
FS-UAE 1200/060 KS/WB 3.9

Some icons are weird, don't know why :

Happen in all mode 8/16/24 Bits RTG or not.

Startup-sequence attached and some "weirds" icons

Hmm ??? Which icons ? There are NO icons in your attachment!
As mfilos already pointed out these files which look weird don't have any icons. And in these cases the default icons are displayed instead as ghosted icons with 50 % transparency. If this is confusing or you simply don't like it then copy the instruction "IconGhostingOff" into C: and call the command in your startup-sequence from a line above LoadWB.

[Foul]

Perfect ! thx

[PeterK]

Update to icon.library 46.4.341:

Some more cleanup in the zlib decoder. The 68000 and 68020 version have both support for MoreLibSpace now if AfA_OS is running, but if not, they use this reserved 7 kB memory block for some of the zlib buffers instead of wasting this space.

[gulliver]

Peter, I am getting 7KB of less memory on a 68000.
Is it reasonable to support AfA_OS on this particular version?
7 KB is some valuable ram on a 512KB system for no real gain

Thanks

[arti]

Peter, which libpng version do use. Do you have some optimized with asm one ?

Cheers

[PeterK]

Originally Posted by gulliver

Peter, I am getting 7KB of less memory on a 68000. ... 7 KB is some valuable ram on a 512KB system for no real gain

Correct!
But this difference exists only as long as you compare the memory allocation while not making any access to at least one OS4 or PNG icon. If you compare after having used the zlib decoding once then there is no difference to 46.4.340 in memory consumption, because the zlib code uses the 7000 bytes which have to be reserved for AfA's MoreLibSpace. The zlib buffers in 46.4.341 should require 960 bytes less now. And I don't want to deal with different zlib buffer concepts for the two CPU versions. ....ok, I thought about it again ....

Update to icon.library 46.4.342:

On special request from gulliver, I've removed the AfA_OS MoreLibSpace support from the 68000 version again to keep the 7 kByte FastMem free as long as no OS4 or PNG icons are displayed.


@arti
My own png decoding is based on the png specification: http://www.w3.org/TR/PNG/

I'm using the zlib v1.14 inflate function extracted from zlib.library 3.2. You can find it in my (PhxAss) source code by searching for "zzz", but it's still under construction, althouigh I've already removed more than 75 % of the terrible redundant original code. My asm source isn't easy to read atm, since I'm still fighting with the zlib algorithm and the hufman decoding.

Important: My png and zlib functions are optimized and limited to decode png icons only. This means that some chunks which are used in png images are not supported and the optimization is done for typical icon sizes and not for screen filling images.

BTW, the funniest thing in the original zlib inflate function was the optimization of the input data stream reading code. Someone must have spent a lot of time and effort to read real large blocks of data as fast as possible and has written quite complex code several times for best optimization, but unfortunately he didn't realized at all that the reading from the input stream would never require more than just maximal 4 bytes (32 bits) at a time.

[PeterK]

Update to icon.library 46.4.343:

Fixed a bug in the 68020 version which appeared with AfA_OS on screenmodes with 15 bits or less. Added some code to detect MoreLibSpace to avoid conflicts with the zlib buffers.

[gulliver]

Originally Posted by PeterK

Correct!
But this difference exists only as long as you compare the memory allocation while not making any access to at least one OS4 or PNG icon. If you compare after having used the zlib decoding once then there is no difference to 46.4.340 in memory consumption, because the zlib code uses the 7000 bytes which have to be reserved for AfA's MoreLibSpace. The zlib buffers in 46.4.341 should require 960 bytes less now. And I don't want to deal with different zlib buffer concepts for the two CPU versions. ....ok, I thought about it again ....

Update to icon.library 46.4.342:

On special request from gulliver, I've removed the AfA_OS MoreLibSpace support from the 68000 version again to keep the 7 kByte FastMem free as long as no OS4 or PNG icons are displayed.

Thank you very much Peter

I have tested version 46.4.343 on 68000, and for now it seems to work wonderfully

[PeterK]

Update to icon.library 46.4.344:

Some more cleanup of the zlib code. Yet another candidate for your critical tests.