CHIP RAM using with Picasso'96

[OSH]

Hmm, it's strange.
I downloaded all GlowIcons, which I found on Aminet. I extracted these to one directory 15450 icons). When I opened directory I saw, CHIP-RAM quickly gone to zero. Why? In Workbench options I have set „other memory” for icons, WinUAE emulates Picasso IV. System OS 3.9
How can I force WinUAE to store icon's data in other memory than CHIP? Even when I set 1 GB 32-bit CHIP, doesn't help...

[Toni Wilen]

Emulator can't affect it. You probably need updated icon.library or other updates to fix it.

[OSH]

Ok, thanks Toni. And one more question: I set over 1,6 GB FAST RAM and launched TinyMeter. After opening directory with these icons I saw, how fast FAST RAM was consumed. But after 800 MB (half of available FAST-RAM) WinUAE freezes. Too many files in one directory? Under DirectoryOpus I see only 5000 of 15450 files...

[PeterK]

These problems with consuming ChipRam and eating up FastMem are mainly caused by DOpus5. It's wasting a lot of ram and also has many memory leaks. For example, when you simply move an icon around on the screen DOpus5 already loses huge amounts of memory. And also the v45 icon.library wastes small amounts of ChipMem and has some memory leaks, too.

Use the OS 3.9 Workbench instead of DOpus5 and install icon.library 46.4:
http://eab.abime.net/showthread.php?t=64079

[OSH]

No no, I'm using Dopus 4.16 under OS 3.9. I'll check this icon.library...

[PeterK]

For 15450 GlowIcons I would expect 100-120 MB FastMem consumption and no ChipMem usage.

But what is the advantage of putting 15450 icons into the same directory? I don't get. It sounds a bit crazy ...

Update:
I just noticed that you are trying to load these Icons into the PicassoIV, but that has only very limited gfx memory. Maybe that could be a problem. Try the native uaegfx screenmodes instead.

[OSH]

Yeah. Now I'm dumb. I'm using UAEGFX not Picasso. My fault...
And why 15450? Because I want to make my system on A4000 more eye-catched, so...

[daxb]

How do you managed to extract so many icons into one directory. Normally that can't work because of naming conflicts. Usually icon packs have several directories if you extract them. On the other hand, generally it is not a good idea to have more then 1000 files in one directory.

[OSH]

I know. How I managed this? Well under FreeCommander. First, I extracted all archives into separate catalogs. Second, I used search function to find all files with .info extension. FreeCommander has a function „Export file container into window”. I used it and have all files in one window (virtually). Then I selected all these files and copied to one directory. For avoiding naming conflict I used function "automatically change the destination name". And voila.

[PeterK]

Did you try to replace icon.library? At least it should not consume ChipMem.

[OSH]

Yes, and did help. But now I have problem with maximal number of icons in one directory. Has AmigaOS a limitation about this? I opened directory with 5000 icons and system hangs... I have 1,4 GB free FAST memory...

[PeterK]

No, Workbench has no problems with reading a drawer with such a large number of files. I've just tried to display my Windows WinSxs directory with more than 19000 sub-directories on WB. Without icons it took less than 3 minutes. "Showing All" directories with deficons really needs a lot of time, especially since I made the mistake to use PNG deficons, which takes 5-6 times as long as GlowIcons. Workbench is busy for half an hour now ....

So be more patient, it's just working, not freezing ...

[OSH]

Hm, ok. And one question: is a program to clean-up icons more efficient and more configurable than system option? I opened directory with 5000 icons, but after using option clean up by name many icons wetre overlapped on others. I tried IconZ from Aminet, but still I have a message "there were errors"...

[PeterK]

Try PIconSnap or PIconGridSnap with a few icons first to understand how to use it: http://aminet.net/package/util/wb/PIconTools

Please remember that the icon x/y position is limited to words = +/- 32768 and each icon needs at least 50 pixels space for width and hight. So, you can not arrange the icons like WB tries to do it, by adjusting one dimension of the window to the screen size (ie. putting only 10 icons into a row) and then using only one slider to scroll through the other dimension (1500 rows). That won't work because 1500 rows with 50 pixels hight are 75000 pixels, which is more than +/-32768 pixels and leads to wrapping and overlapping effects. But you can arrange your icons as 100x150.

I fear that there are some components somewhere in Windows or AmigaOS with non-linear time demand (exponential growth) in relation to the number of files in a directory. Workbench is still busy ...

Hey, it's done now, after nearly 2 hours Workbench has finished the job of loading more than 19000 PNG deficons. But icon.library usually can process 100x190 icons in a few minutes. Don't know what's slowing down here so much ??

[daxb]

Maybe the used filesystem behaves different then others? Listing files can be fast or slow depending on used program. DOpus4 is much slower then DOpus5 for example. Workbench was always slow. On a classic Amiga list/show several hundred icons took ages.

[Daedalus]

Yeah, if you're using FFS, traversing directories gets slower the more files you have in it. Having thousands and thousands of files that all have to be loaded to view the directory contents is a little nuts to be honest...