icon.library 46.4 test versions

[AMIGASYSTEM]

Originally Posted by PeterK

But why do you want to use the original Aros 68k icon.library again? What are you missing in my library or what is not working as desired? Or do you plan to sell your distros for more than 10 € in the future?

No I don't want to change also because with your icon.library the mentioned tools all work well. To have a native AROS icon.library that works is a comfort, who uses a different Distribution from mine would see badly my icons.

Your icon.library is always present in LIBS, but if someone replaces the startup-sequence or modifies it there will be no problems with PNG icons, only thing the mentioned tools will not work.

[AMIGASYSTEM]

Originally Posted by PeterK

Old programs which have been written for planar icons or ColorIcons can't handle newer icon formats, so icon.library must convert the images for them and sometimes it also has to do a lot of cheating or patching in order to let them work with TrueColor icons.

The good miker has created an App called IconClone for AROS 68k, Aros x86 and Aros 64 that allows you to change images between DualPNG icons.

https://ae.amigalife.org/index.php?topic=814.75

[PeterK]

That's great, Carlo ...
... but I can't see a download link for IconClone. Do I need an account to get that tool?

[AMIGASYSTEM]

Yes, You must be logged in otherwise you don't see the attachments!

[PeterK]

Update to icon.library 51.4.558_TC020:

 "Tricky Drag°n" allows icon dragging in true RGB colors
 and with soft alpha channel fading at the borders with
 P96 on Workbench 3.0-3.9 for OS4 and PNG icons and RGB
 for palette based ColorIcons and NewIcons. This should
 also work with P96 v3.x, but I can't test new versions.

 CGX4 and Cyberbugfix are supported again when SuperGels
 are enabled. DOpus5 icons on native screens are fixed.

 For some configurations the delayed image decoding of
 the selected icons is not immediately possible for the
 invisible icons which are at positions outside of the
 current window view. If you click on "Select all icons"
 and drag them around then the "hidden" icons may appear
 as half transparent or striped rectangles or small dots.
 The delayed decoding improves the window opening speed.

[apex]

Here it is working in my configuration like always. A2000/030/RTG and A1200/060/AGA.

[AMIGASYSTEM]

Perfect Peter, tested on OS 3.9 BB4 RTG and OS 3.2 RTG, when dragging the icons remain of the same quality.

On AfA One for the reasons we know is not influential because even with previous versions of Icon.library you got the same result.

[PeterK]

Originally Posted by apex

Here it is working in my configuration like always. A2000/030/RTG and A1200/060/AGA.

Thanks a lot for your feedback, apex!

On the AGA system it may have a little advantage now to use the P96 native monitor driver, because then you will get real images for the "hidden icons" outside of the visible window view when you drag them around. Without P96 (but FBlit instead) the native modes are one of the problem cases on Workbench v44+ and you will only see dots for those "hidden icons" when you click "Select All" in the WB menu and drag one of the visible icons around. Speed is still a little bit better with FBlit here, but not noticeable.

But how about the speed on your 030/RTG ZII system? Is that fast enough for OS4 or PNG icons and TrueColor dragging. I've doubt about that TrueColor icons are really usable there, although I can't test it. But my A2000 with 2620, 2091 was not even fast enough for GlowIcons in the 90'th, and I could never test it with my icon.library. Now it's somewhere on the dump already.


@Carlo
Yeah, on WinUAE RTG systems with WB v44+ dragging should look much better now. After I found a solution to implement the new TrueColor dragging, I noticed that AfA_OS seems to do it in a similar way. I always thought that AfA has it's own dragging routine like DOpus5, but no, it also seems to patch the blitter function calls. That's probably the reason why the planar images of AfA always have these bit patterns in the upper row of the images. There are the pointers to the icon data stored, and I'm using the same trick now for the dragging, because the bitmap data might just be a copy of the original image, and there is no other possibility to transfer the pointers to gfx-patch. This has caused a lot of trouble with CGX4, because it seems to overwrite these first longwords partially, and I had to add a strong protection for this data to detect any damage for sure in order to avoid memory trashing by using wrong pointers. The difference to the AfA_OS solution is that it stops dragging the icons as soon as they touch the screen borders, whereas my patch then falls back to the original planar bob images of the blitter function calls.

[hexaae]

@PeterK
Some issues using Processicon http://m68k.aminet.net/package/util/wb/ProcessIcon trying to copy ColorIcon on the old icon in this archive: https://gofile.io/d/ck23N4

Try:
ProcessIcon CCI <oldicon> <newCI>

You'll notice 2nd image of copied CI will be corrupt. Won't happen using icon.library 44.x or 45.x

P.S.
I use C:NoDelayedImage2 in my User-Startup...

[PeterK]

Thanks for reporting It sounds like an issue or side effect with my delayed decompression of the second image (RLEjit). I will check that soon ... I'm glad that at least some people are testing other things, too.

The option "NoDelayedImage2" was abolished some releases ago and has no effect anymore, because delaying the decompression, color reduction, color mapping and chunky to planar conversion of the second images makes icon loading much faster.

[hexaae]

Is it possible to forcibly re-add pixel-dithered dragging for TC icons? I loved it

[PeterK]

The ProcessIcon issue with the 2. image was indeed caused by the missing decompression (RLEjit), but after some investigation I found a strange reason for it. ProcessIcon uses GetIconTagList() with the option "GetPaletteMappedIcon, FALSE", but then it wants to get the data of this palette mapped icon! I didn't expect that to happen, and I was a bit surprised, because it did always work before, probably even with all my older versions (maybe up to #549). My RLEjit was only prepared for cases where a tool didn't want to do the color mapping like IconEdit or AsyncWB (using "remap, FALSE"), then the decompression was done immediately.

I will fix that today, but at the moment there are a lot of other changes in the IconLib code, I've split my source into two branches, one for the old (outdated) 68000 and 68020, and the other one for all the TrueColor versions. This allows me to get rid off most compiler options, all these ugly "ifd option, else, endif" code fragments, which make the code less readable. These changes are still WIP and need a lot of testing, but maybe I can release an intermediate test version with the fix soon ... ?

Is it possible to forcibly re-add pixel-dithered dragging for TC icons? I loved it

If you mean this poor quality color mapped planar icon dragging, why should I keep that alive? No, it's too difficult to make it optional, because the changes are spread over several parts of the code and it would require many additional option checks and branches, causing larger and slower code.

[PeterK]

Update to icon.library 46.4.559, 47.-1.559, 51.4.559: (on the 1. page)

Fixed a bug in the delayed decompression of the 2. image of ColorIcons (RLEjit) for a ProcessIcon issue. - Removed all WB 3.1 related code from the Aros version.

[AMIGASYSTEM]

Thanks Peter, i tested the version AROS on my AROS One 68k and it works perfectly !

[PeterK]

Thanks Carlo!

Up to now, with this intermediate test version #559, there are still no real optimizations for the icon dragging with Wanderer on Aros or for the standard dragging functions in DOpus5. That needs more investigations and experiments, because everything works different compared to WB and P96. Maybe, it's not possible at all for me to improve the icon dragging in Wanderer, because it seems to have very special routines for handling the background. The dragging on 8-bit or planar screens is still totally broken. But first I want to improve the standard dragging in DOpus5 to get the same results as on Workbench.

And I could also try to reduce the amount of (A)RGB data that has to be transferred between the gfx-card and the CPU by shrinking the size if the image rectangles to the minimal required visible parts without the transparent border areas, as this is already done for the direct drawing of ColorIcons.

[hexaae]

This glitch reappeared at some point... and NoDelayedImage2 no longer works...
http://eab.abime.net/showpost.php?p=...postcount=2437

If you mean this poor quality color mapped planar icon dragging, why should I keep that alive? No, it's too difficult to make it optional, because the changes are spread over several parts of the code and it would require many additional option checks and branches, causing larger and slower code.

Mmmh, I asked for it to keep it coherent with normal icons (old 3.1 standard) dragging which still uses it even with your TC020 icon.library. In case could you make all icon types (NI, Standard, CI...) dragging opaque to keep coherent look?

[PeterK]

Originally Posted by hexaae

This glitch reappeared at some point... and NoDelayedImage2 no longer works...
http://eab.abime.net/showpost.php?p=...postcount=2437

This only happens with WB v44+, but no P96. It's one of the cases where I couldn't find a solution to patch the blitter calls for the "hidden" icons outside of the window view. With a P96 "native" monitor driver instead of FBlit it should disappear.

Mmmh, I asked for it to keep it coherent with normal icons (old 3.1 standard) dragging which still uses it even with your TC020 icon.library. In case could you make all icon types (NI, Standard, CI...) dragging opaque to keep coherent look?

I still don't understand what you really want? Do you want the selected icon under the mouse pointer to be half-transparent (every 2. pixel) again on TrueColor screens? This masking-effect is done by the dragging routine of the Workbench and the blitter, but for TrueColor dragging I don't use these blitter function calls anymore, except when you drag the icons onto the edge of the screen. Then you can see the dithered blit-mask again. I'm still not finished with my new dragging code. Remember, these are all just test versions, but I can not promise to find a good (fast) solution for making the icon under mouse pointer half-transparent again, because I would have to retrieve the mouse position first, which could be difficult in the gfx-patch. The same problem exists for the ghosted deficons. WIP.

[hexaae]

Originally Posted by PeterK

This only happens with WB v44+, but no P96. It's one of the cases where I couldn't find a solution to patch the blitter calls for the "hidden" icons outside of the window view. With a P96 "native" monitor driver instead of FBlit it should disappear.

Mmmh, I use P96 (RTG WinUAE Zorro 3 gfx board) and OS3.9...

I still don't understand what you really want? Do you want the selected icon under the mouse pointer to be half-transparent (every 2. pixel) again on TrueColor screens?

Exactly Just for coherence with std 3.1 icons dragging where I can see the same effect.

[PeterK]

I have no dot images for the hidden icons here with P96 v2.x and WB 45.194 or 45.132, but you said that you have P96 v3.x.

Could you please test it again with an older rtg.library and emulation.library of P96 v2.x.

What are your PVS settings for the P96 ENV: variables and the UAEgfx monitor tooltypes?

[hexaae]

Not for the hidden files... I meant for the normal dragging of old icon Standard format, not necessarily hidden.



As you can see standard 3.1 icons look checkered on dragging...
Using Picasso96 install from Aminet with WinUAE Zorro 3 gfx board emu in this test.

UAEgfx monitor driver settings:

(BorderBlank=System)
(MemoryClock=0)
(Quiet)
BigSprite=NO
BoardType=uaegfx
DisplayChain=Yes
FakeNativeModes=NO
FontsFix=NO
GrantDirectAccess=NO
IgnoreMask=NO
NoBlitter=NO
NoPlanar2ChunkyBlits=NO
OverClock=NO
SettingsFile=SYS:Devs/Picasso96Settings
SoftSprite=Yes
System2ScreenBlits=NO

ENV:

[6.Workbench:] ls ENV:Picasso96/
Directory "ENV:Picasso96" on Sabato 08-Gen-22
AlertSupport                         2 ----rwed Oggi      15:48:10 ('No' for all 2bytes files...)
AmigaVideo                           5 ----rwed Oggi      15:48:10 (15KHz)
AreaEndSupport                       3 ----rwed Oggi      15:48:10 (Yes)
BlackSwitching                       2 ----rwed Oggi      15:48:10
Debug                                2 ----rwed Oggi      15:48:10
DirectColorMask                      2 ----rwed Oggi      15:48:10
DisableAmigaBlitter                  2 ----rwed Oggi      15:48:10
DoNotSetMMU                          2 ----rwed Oggi      15:48:10
EnableBootVGA                        2 ----rwed Oggi      15:48:10
Experimental                         2 ----rwed Oggi      15:48:10
PlanarOnlyDIPFDBUF                   2 ----rwed Oggi      15:48:10
PlanesToFast                         3 ----rwed Oggi      15:48:10 (Yes)
ShowModes                            3 ----rwed Oggi      15:48:10 (Yes)