icon.library 46.4 test versions - Page 20

fitzsteve · 15 March 2013, 18:33

Nice I look forward to testing on my A1200

fitzsteve · 16 March 2013, 12:48

Just tested on my A1200 (ACA1232/33 & Indivision AGA MkII in SuperPlus 800x600)

Using kens Icons v3 on OS3.9 Classic, indeed it seems at least 20% faster, very nice work as always

PeterK · 17 March 2013, 01:32

Quote:

Originally Posted by mfilos

It's indeed a lot faster!
I tried it just some minutes ago in my A600@36MHz and it's really fast on Ken's Icons and MasonIcons testing. It seems like at least double the speed.
NewIcons and MagicWB icons almost load instantly.

Perfect update

Hehe, mfilos, my friend !!
I've got you here: http://mfilos.blogspot.de/

Quote:

Some of the new stuff I tinkered on my Workbench installation was to install PeterK's 46.4.279 icon.library which give a nice 15-20% speed increase from what I can tell. Really shows nicely when I open PNG etc icons but I will let you be the judge of that

That's closer to the truth, I guess

mfilos · 17 March 2013, 02:46

LOL the latest was based to most of the guys verdict here

More or less... it ROX \m/

PeterK · 17 March 2013, 15:28

Since a user at A1k.org has asked me for something that can load the icons into the 16-bit Fast-Ram in order to save the more valuable 32-bit FastMem for real applications, I've made another short instruction for the startup-sequence. If you want to use it then your 32-bit FastMem must be located above the 24-bit address space. This is either Z3-Ram or it can also be the accelerator memory. The instruction should be started just before LoadWB:

mfilos · 17 March 2013, 18:44

I've been meaning to ask you about that

What is the difference between the "IconsTo24BitDmaMem.lha" and "IconsTo24BitFastMem.lha" ?

So just a declaration of C:IconsTo24BitDmaMem before loadwb would suffice?

PeterK · 17 March 2013, 19:09

Ehm, mfilos...
... I didn't upload the second instruction here to avoid any confusion..
but, it didn't help, as I see now.

So what is the difference?
24-bit (address space) DMA memory can also be the ChipMem, not only the FastMem with the MEMF_24BITDMA attribute. So, as soon as all the 16-bit (data size) FastMem is in use then the icons would go into the ChipMem, too.

The other instruction has also the attribute MEMF_FAST set in combination with MEMF_24BITDMA, and thus the usage is restricted then to the 16-bit FastMem only. Don't use that instruction.

Yes, starting the instruction before LoadWB is correct.
Of course, loading the icons into 16-bit memory may take a little longer than using 32-bit memory.

mfilos · 17 March 2013, 22:16

OK now everything's clear (sorry for asking)

I see no point in using it anyway. 32bit memory is no problem for 99% of the people with an accelerator for putting just some icons.

NovaCoder · 19 March 2013, 01:05

Peter,

Just installed v46.4.279, very good speed, well done (icon's open almost instantly even with 800x600 8bit AGA).

I have noticed the color mapping is a bit different with this version. I use 'FixedPalette' and had my color mapping set to ICONS before, this gave me a nice WB background picutre, with 46.4.279 I have change the color mapping to IMAGE to get the same effect.

I guess it's actually working the right way now?

PeterK · 19 March 2013, 02:49

Hmmm

I did not change the colormapping procedure. The only thing I've modified lately was the conversion from alphachannel fading into transparency by using two steps with 75 % and 50 % RGB now before switching to the background. This should improve the appearance of the icon borders a little. Usually, I prefer to set the icon quality either to best or worst on a truecolor screen, but you may want to keep some pens free for your background picture on AGA. That's ok.

NovaCoder · 19 March 2013, 03:45

Ok I changed the icon quality to 'poor' from 'best' and that improved the background picture again. I have a feeling that the older icon.library was ignoring the quality setting for AGA (eg it was always poor).

Icons don't appear to look any worse on my setup when I set the quality to poor BTW.

PeterK · 19 March 2013, 04:38

Icon quality precisions are named EXACT=BEST, IMAGE=GOOD, ICON=POOR or GUI=BAD. Only the latter is using the faster colormapping with the 512 byte cache.

First you said that you changed from ICON to IMAGE, and now from BEST to POOR=ICON. Does this mean that you're now back to settings where you started from ?

It depends on the colors used by the background image and the first icons that are decoded how the screnns colormap is finally set up. EXACT=BEST will not automatically give the best results in any case.

NovaCoder · 19 March 2013, 09:48

No I used to have FixedPalette mapping set to ICON and WB Prefs Quality set to 'best', now I've got my FixedPalette mapping to IMAGE and have changed my WB Prefs Quality to 'poor'.

Ok, well I'm happy now anyway

Fast icons and a nice background, thanks.

PeterK · 19 March 2013, 10:40

Ahh, now I understand what you have changed. Two different preferences. Thanks for clarifying this miracle.

PeterK · 03 April 2013, 01:48

Update to icon.library 46.4.280

After hesitating for long I thought it's time now for releasing a very early beta version of the first icon.library with an embedded zlib inflate function.

Retrofan · 03 April 2013, 02:30

Eeeh, yes, yes. Thank's... What's that, please?

PeterK · 03 April 2013, 02:43

Quote:

Originally Posted by Retrofan

Eeeh, yes, yes. Thank's... What's that, please?

Sorry, but I don't know.
Ask Huffman. please !!

mfilos · 03 April 2013, 15:04

I'll be damned it works!!!

That is some crazy shiz now there my friend. Kudos!
Just to be sure... I renamed zlib.library using the previous icon.library version and MasonIcons and KensIcons didn't load (logical).
I then made the new ROM with the newest icon.library and all worked just fine.
I could say there is a slightly increase in speed (about 5-10%) loading these icons now!

Congratz again man. Impressive work \o/

Retrofan · 03 April 2013, 19:40

I've just copied it to libs like always and I don't see any speed improvement at all. Perhaps I am missing something.

altcomputing · 04 April 2013, 09:27

Does AfA_OS patch icon.lib completely rendering your library useless? If so, I am starting to think of abandoning (slow) AfA in favor of this lib

17 March 2013, 15:28	#385
PeterK Registered User Join Date: Apr 2005 Location: digital hell, Germany, after 1984, but worse Posts: 3,378	Since a user at A1k.org has asked me for something that can load the icons into the 16-bit Fast-Ram in order to save the more valuable 32-bit FastMem for real applications, I've made another short instruction for the startup-sequence. If you want to use it then your 32-bit FastMem must be located above the 24-bit address space. This is either Z3-Ram or it can also be the accelerator memory. The instruction should be started just before LoadWB: Last edited by PeterK; 12 April 2022 at 12:37.

19 March 2013, 04:38	#392
PeterK Registered User Join Date: Apr 2005 Location: digital hell, Germany, after 1984, but worse Posts: 3,378	Icon quality precisions are named EXACT=BEST, IMAGE=GOOD, ICON=POOR or GUI=BAD. Only the latter is using the faster colormapping with the 512 byte cache. First you said that you changed from ICON to IMAGE, and now from BEST to POOR=ICON. Does this mean that you're now back to settings where you started from ? It depends on the colors used by the background image and the first icons that are decoded how the screnns colormap is finally set up. EXACT=BEST will not automatically give the best results in any case. Last edited by PeterK; 19 March 2013 at 04:51.

19 March 2013, 09:48	#393
NovaCoder Registered User Join Date: Sep 2007 Location: Melbourne/Australia Posts: 4,406	No I used to have FixedPalette mapping set to ICON and WB Prefs Quality set to 'best', now I've got my FixedPalette mapping to IMAGE and have changed my WB Prefs Quality to 'poor'. Ok, well I'm happy now anyway Fast icons and a nice background, thanks. Last edited by NovaCoder; 19 March 2013 at 10:07.

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
ClassicWB Full and icon.library 46.4	Retroplay	project.ClassicWB	8	05 August 2018 13:57
WB library conflict/versions	Amiga1992	support.Apps	3	22 July 2010 18:47
PNG Icon to Color Icon Converter?	Leandro Jardim	request.Apps	1	24 May 2010 04:39
What's the latest version of icon.library for OS3.9?	NovaCoder	support.Apps	3	30 June 2009 15:43
Requesting icon.library v44+...	nikvest	request.Other	2	16 September 2007 01:58

15 March 2013, 18:33	#381
fitzsteve Professional slacker! Join Date: Jul 2009 Location: Kent, UK Age: 44 Posts: 6,683	Nice I look forward to testing on my A1200

16 March 2013, 12:48	#382
fitzsteve Professional slacker! Join Date: Jul 2009 Location: Kent, UK Age: 44 Posts: 6,683	Just tested on my A1200 (ACA1232/33 & Indivision AGA MkII in SuperPlus 800x600) Using kens Icons v3 on OS3.9 Classic, indeed it seems at least 20% faster, very nice work as always

17 March 2013, 02:46	#384
mfilos Paranoid Amigoid Join Date: Mar 2008 Location: Athens/Greece Age: 45 Posts: 1,978	LOL the latest was based to most of the guys verdict here More or less... it ROX \m/

17 March 2013, 18:44	#386
mfilos Paranoid Amigoid Join Date: Mar 2008 Location: Athens/Greece Age: 45 Posts: 1,978	I've been meaning to ask you about that What is the difference between the "IconsTo24BitDmaMem.lha" and "IconsTo24BitFastMem.lha" ? So just a declaration of C:IconsTo24BitDmaMem before loadwb would suffice?

17 March 2013, 19:09	#387
PeterK Registered User Join Date: Apr 2005 Location: digital hell, Germany, after 1984, but worse Posts: 3,378	Ehm, mfilos... ... I didn't upload the second instruction here to avoid any confusion.. but, it didn't help, as I see now. So what is the difference? 24-bit (address space) DMA memory can also be the ChipMem, not only the FastMem with the MEMF_24BITDMA attribute. So, as soon as all the 16-bit (data size) FastMem is in use then the icons would go into the ChipMem, too. The other instruction has also the attribute MEMF_FAST set in combination with MEMF_24BITDMA, and thus the usage is restricted then to the 16-bit FastMem only. Don't use that instruction. Yes, starting the instruction before LoadWB is correct. Of course, loading the icons into 16-bit memory may take a little longer than using 32-bit memory.

17 March 2013, 22:16	#388
mfilos Paranoid Amigoid Join Date: Mar 2008 Location: Athens/Greece Age: 45 Posts: 1,978	OK now everything's clear (sorry for asking) I see no point in using it anyway. 32bit memory is no problem for 99% of the people with an accelerator for putting just some icons.

19 March 2013, 01:05	#389
NovaCoder Registered User Join Date: Sep 2007 Location: Melbourne/Australia Posts: 4,406	Peter, Just installed v46.4.279, very good speed, well done (icon's open almost instantly even with 800x600 8bit AGA). I have noticed the color mapping is a bit different with this version. I use 'FixedPalette' and had my color mapping set to ICONS before, this gave me a nice WB background picutre, with 46.4.279 I have change the color mapping to IMAGE to get the same effect. I guess it's actually working the right way now?

19 March 2013, 02:49	#390
PeterK Registered User Join Date: Apr 2005 Location: digital hell, Germany, after 1984, but worse Posts: 3,378	Hmmm I did not change the colormapping procedure. The only thing I've modified lately was the conversion from alphachannel fading into transparency by using two steps with 75 % and 50 % RGB now before switching to the background. This should improve the appearance of the icon borders a little. Usually, I prefer to set the icon quality either to best or worst on a truecolor screen, but you may want to keep some pens free for your background picture on AGA. That's ok.

19 March 2013, 03:45	#391
NovaCoder Registered User Join Date: Sep 2007 Location: Melbourne/Australia Posts: 4,406	Ok I changed the icon quality to 'poor' from 'best' and that improved the background picture again. I have a feeling that the older icon.library was ignoring the quality setting for AGA (eg it was always poor). Icons don't appear to look any worse on my setup when I set the quality to poor BTW.

19 March 2013, 10:40	#394
PeterK Registered User Join Date: Apr 2005 Location: digital hell, Germany, after 1984, but worse Posts: 3,378	Ahh, now I understand what you have changed. Two different preferences. Thanks for clarifying this miracle.

03 April 2013, 01:48	#395
PeterK Registered User Join Date: Apr 2005 Location: digital hell, Germany, after 1984, but worse Posts: 3,378	Update to icon.library 46.4.280 After hesitating for long I thought it's time now for releasing a very early beta version of the first icon.library with an embedded zlib inflate function.

03 April 2013, 02:30	#396
Retrofan Ruler of the Universe Join Date: Mar 2010 Location: Lanzarote/Spain Posts: 6,195	Eeeh, yes, yes. Thank's... What's that, please?

03 April 2013, 15:04	#398
mfilos Paranoid Amigoid Join Date: Mar 2008 Location: Athens/Greece Age: 45 Posts: 1,978	I'll be damned it works!!! That is some crazy shiz now there my friend. Kudos! Just to be sure... I renamed zlib.library using the previous icon.library version and MasonIcons and KensIcons didn't load (logical). I then made the new ROM with the newest icon.library and all worked just fine. I could say there is a slightly increase in speed (about 5-10%) loading these icons now! Congratz again man. Impressive work \o/

03 April 2013, 19:40	#399
Retrofan Ruler of the Universe Join Date: Mar 2010 Location: Lanzarote/Spain Posts: 6,195	I've just copied it to libs like always and I don't see any speed improvement at all. Perhaps I am missing something.

04 April 2013, 09:27	#400
altcomputing MC68060@85MHz Join Date: Jan 2011 Location: Poland/Wroclaw Age: 38 Posts: 76	Does AfA_OS patch icon.lib completely rendering your library useless? If so, I am starting to think of abandoning (slow) AfA in favor of this lib

Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)