icon.library 46.4 test versions

[AMIGASYSTEM]

Ciao PeterK, Don't call me a pain in the ass

Found anomaly of your icon.library on AfA OS, see full small video

https://drive.google.com/open?id=1a_...NFYn5MTmhmG1Kd

[PeterK]

Don't call me a pain in the ass

What? Where did I do that or why should I say such nonsense?

No Carlo, that's an anomaly of AfA's icon_lib.exe which has no support for the Workbench preferences settings "No ColorIcon" or "No NewIcon" and just ignores these switches. My library and the AmigaOS icon.library are correctly displaying the planar images as intended by this WB option.

[AMIGASYSTEM]

Originally Posted by PeterK

What? Where did I do that or why should I say such nonsence?
.

it's an Italian expression (spero di non rompere le scatole) when a person thinks he's annoying!


Yes but with the icon_lib.exe everything works well

[PeterK]

Ok, keep your (non)sense of humor. It's not annoying!

[CMTX]

Hello thread! I'm sure this has already been discused but hard to tell between 162 pages I'm using the tc_020 version of your library (46.4) with opus5.91 and it eats memory badly. I guess it's a compatability problem with dopus because workbench works fine. Has anyone experienced the same behaviour as me, is there a workaround? Maybe another version of the library or dopus 5.82 works fine, i have to test it yet!

Cheers

Edit: I've tried with the icon.library that comes with os3.1.4 and it shows the same behaviour. Definitely there is something broken on dopus 5.91, i'm gonna try 5.82 hoping everything will be fine

[daxb]

In DOpus 5 preferences you can set several icon related settings that might be worth a check.

[PeterK]

No, it's the sad truth, but DOpus5 has several bugs causing memory losses, no matter whether you use v5.8 or v5.9. The latter has fixed some old bugs and introduced new ones instead. I would not recommend 5.9.

DOpus5 has a small FastMem leak when you open and close windows with icons, but it also has a huge leak when you just drag icons around on the screen, which causes really heavy memory losses.

Sorry, but I don't want to fix these bugs in DOpus5. PCs have enough memory nowadays to live with it for some hours.

In any case, I prefer to use the Workbench or Windows. At least on Aros 68k DOpus5 is still a better choice than Wanderer.

[PeterK]

Update to icon.library 46.4.522:

Upgraded the HAM6 and HAM8 versions to v51 in order to display the Eastern picture preview icons in full HAM quality instead of dithered images. Of course, I know that a HAM-WB is more a tech demo than something useful, but picture files are the best to demonstrate that. You can compare the results with the v46 versions and tell me what you'd like to have in future.

The "Alpha" version has been renamed to "Aros" now and I've added some more support for Wanderer, which is treated like a replacement for the Workbench task. With this trick Wanderer can also avoid the color reduction and delay the color mapping of the second image in the same way as the Workbench. The usage of FastMem is now enabled by default on Aros. Nevertheless, Wanderer is still slower than DOpus5 on the same system and much slower than WB on AmigaOS 3.x.

The other target versions have no functional changes, as I hope.

[AMIGASYSTEM]

Originally Posted by PeterK

In any case, I prefer to use the Workbench or Windows. At least on Aros 68k DOpus5 is still a better choice than Wanderer.

I wouldn't so much agree



https://drive.google.com/file/d/1ogE...J4x7wdi6P/view


https://drive.google.com/file/d/15kS...WU5ncHRAN/view

[PeterK]

Originally Posted by AMIGASYSTEM

I wouldn't so much agree

Well, I'm already happy if you would agree a little bit ...

Btw, how fast is your PC? Maybe an i9 with 5 GHz?
Or is your Wanderer running in a data processing center in the cloud?

[AMIGASYSTEM]

Old PC

Pentium (R) Dual-Core CPU E6300 2.80 GHz
RAM 4 GB
OS Win7 32 Bit
Video Card ATI Radeon HD 5450

In the video your Library was used

[CMTX]

Originally Posted by PeterK

No, it's the sad truth, but DOpus5 has several bugs causing memory losses, no matter whether you use v5.8 or v5.9. The latter has fixed some old bugs and introduced new ones instead. I would not recommend 5.9.

DOpus5 has a small FastMem leak when you open and close windows with icons, but it also has a huge leak when you just drag icons around on the screen, which causes really heavy memory losses.

Sorry, but I don't want to fix these bugs in DOpus5. PCs have enough memory nowadays to live with it for some hours.

In any case, I prefer to use the Workbench or Windows. At least on Aros 68k DOpus5 is still a better choice than Wanderer.

Too bad, going back to Dopus4 then

BTW thank you for your work on this!! It makes my amigan life much easier

[PeterK]

Update to icon.library 46.4.523:

Another small optimization in the color reduction code for OS4 and PNG icons, especially for icons with more than 223 colors like for many WHDLoad games. I've also fixed some rare "holes in the cheese" when no matching color could be found or allocated. Now in such a case only pixels on the left border are made transparent, but all others are getting the color of the previous pixel.

[AMIGASYSTEM]

Thanks Peter

I released my AROS One x86 (what do you think), I must say that the Icon.library of this OS is very good, it's a pity that on AROS x86 there are no tools to change Icon and change Icon Type

Always fast on mine PC Dual-Core

Tutorial Video: AROS One x86 - VMWare

Tutorial Video: AROS One x6 - VirtualBox

[PeterK]

Very impressive demos of your Aros One x86 distros, but much too long for watching all of it. I think you made a good job, the only problem is that I'm the wrong customer for Aros.

Atm, I have problems to update Aros 68k with the lastest nightly builds. The new Roms are not working with my old version from December (commands in C: can't be executed) and the Installer copies just nothing from the ISO image to my existing WinUAE Aros drawer as it always did before with previous updates.

(Btw, I could make my Aros 68k a lot faster now after moving the WinUAE CPU Idle slider to the left side like in all my other configs. Don't know how that mistake could happen in the Aros settings.)

[AMIGASYSTEM]

If you want to test my Config UAE (replaced)

[PeterK]

Thanks Carlo, but my Aros 68k config usually works. But I'll check your config out.

[apex]

Hello Peter,
I have here a problem with the latest release x520 TC020 on my A2000 with AmigaOS 3.1.4.1 which is running a mix of icons: Old 1.3, 3.1, MagicWB, 3.9... It seems I am no more able to snapshot all of them. After opening the window again, they are on their old position again. I tried now the icon.lib coming with 3.1.4 and it is working there, but much slower. Do you changed something on the snapshot function?

[PeterK]

Hello apex, nice to hear something from you again. I hope you're well.

At the moment, I can not reproduce any problems with icon snapshot on OS 3.1.4. All what I can remember from 3.9 concerns "left out" icons on the Workbench screen, which sometimes can't be fixed on certain positions, although the x/y values are correctly stored in the icons. But for unknown reason Workbench handles them as icons without a position (like after unsnapshot). This strange behavior may also depend on the order of the names in the ".backdrop" file(s). But that's a WB problem.

The other exception are fake icons, alias deficons or ghost icons, which you can't snapshot. You can convert them into real icons with SwazInfo or RAWBInfo, but not with the standard WBInfo of the OS.

Or are some of your #?.info files readable only? Check the protection flags of the icons, not from the files.

Are that always the same icons and the same positions where you can't snapshot? If there are particular problem icons please upload some of them.

Is it only a certain filesystem where this happens?

[PeterK]

The full icon.library 46.4.524 package is available at Aminet.

Update to icon.library 46.4.525 (here, at the first page):

A small decoding speed improvement for ColorIcons, especially for those with more than 128 colors, like BoxIcons. I've optimized my very old RLE decompression and added an extra mode for 8 bit color depth avoiding the bit processing.

Update to icon.library 46.4.526:

Optimized the same code a bit more again. A few instructions and bytes less.

Ooops, there was still the old source file in the 526 package included. Swapped now!