icon.library 46.4 test versions

[PeterK]

The ChipMem consumption in DOpus5 is nothing new. I cannot change that. And it seems that I also cannot fix the image corruptiin when dragging icons, and thus I will probably remove the delayed mapping for DOpus5 again. I really hate DOpus Magellan !!

[PeterK]

Update to icon.library 46.4.392:

The icon.library is back!
This a completely new approach to make the icon loading under DOpus5 a bit faster on Hi/TrueColor screens. Instead of delaying the colormapping, it is not done at all anymore when you disable it with the command DOnoColorMapping in your startup-sequence. In order to get correct images while dragging the icons around, you have to enable "Use Custom Drag Routines" in the DOpus5 settings and it's recommended to disable the "Fast Icon Dragging", too.

There is also a new library version with the extension "lined" included in the attachment. This is for the Amithlon or other systems, which run faster with the old direct drawing code that was transferring the icon images line by line to the gfx-card and not in just one block.

[Retrofan]

It's "Quick Icon Dragging". I will try (I've got it like that).

Edit: It works very fast and right, but I don't seem to need the DOnoColorMapping in the s-s. What problem should I notice? I mean I can move ten icons at the same time on screen and I don't see anything wrong.

[Michael]

icon.library 46.4.392 under DO CGX 16bit:

Crystal pack = 7.20s
Kens pack = 16.36s

So performance is back to v388 and transparent dragging works!

Enabled DOnoColorMapping...

Now all icons when dragging are missing 100%.

Enabled custom drag routines

Icons are dragged ok now (good for AGA) but not for CGX
since we lack transparency effect and they flicker madly

Performance boost, yes!

Crystal pack = 4.696s v (5.44s in v390)
Kens pack = 14.120s v (14.42s in v390)

But personally I prefer the slower method, since it looks better.

And with DOnoColorMapping enabled, IconInfo to IconInfo icon copy no longer works
and produces empty icon. (new bug )

[Michael]

"Quick Icon Dragging" - this disables the transparent icon background. (useful for MWB only).

[PeterK]

Originally Posted by Michael

icon.library 46.4.392 under DO CGX 16bit:

Crystal pack = 7.20s
Kens pack = 16.36s

So performance is back to v388 and transparent dragging works!

That's exactly as it should be.

Enabled DOnoColorMapping...

Now all icons when dragging are missing 100%.

Ok, also as expected when custom drag routines are off. The faked planar images are 100 % set to zeros = nothing to see, except the background.

Enabled custom drag routines

Icons are dragged ok now (good for AGA) but not for CGX
since we lack transparency effect and they flicker madly

What do you mean with transparency effect? 50 % ghosted while dragging? That's only on CGX4 but on P96 they are always solid images with a masked background (100% or nothing). Not much flickering here on WinUAE.

Performance boost, yes!

Crystal pack = 4.696s v (5.44s in v390)
Kens pack = 14.120s v (14.42s in v390)

But personally I prefer the slower method, since it looks better.

And with DOnoColorMapping enabled, IconInfo to IconInfo icon copy no longer works
and produces empty icon. (new bug )

The performance gain is nice. DOpus IconInfo is an absolute desaster. Forget it.

[Michael]

Yes. 50% real ghosting (transparency), like on WB too.

[PeterK]

And with DOnoColorMapping enabled, IconInfo to IconInfo icon copy no longer works and produces empty icon. (new bug )

No, only the IconInfo box looks and seems to be empty, because the planar image is just a fake made completely with color 0 (invisible), but when you save the IconInfo and then reload the drawer, everything is fine and the image was indeed copied.

[PeterK]

Update to icon.library 46.4.393:

This version has an improved icon dragging when "Use Custom Drag Routines" is disabled in DOpus5 icon settings. Instead of showing just nothing for the dragged icon images it now displays a 50 % transparent, gray image mask of the selected icon. This is a compromise and if you don't like it then enable the custom drag routines again or don't use the DOnoColorMapping command. (There is no ghosting effect on Aros Vision). But the icon rendering is a little faster again.

[Michael]

Small improvement on speed (393) with DOnoColorMapping
Crystal pack = 4.656s v (4.696s in v392)
Kens pack = 14.100s v (14.120s in v392)

The shadow/ghost effect is nice, better then nothing, and maybe someone will like it.

New bug. With DOnoColorMapping active, under WB a selected dragged icon gets a grey background instead of full transparency. Does not effect other icons in the selected group.

[PeterK]

Can't reproduce that "bug" under WB 3.9, not even when WB 3.9 an DOpus5 are running at the same time. Is that with WB 3.1 ?

Ok, it seems to have some side effects when WB and DOpus5 are both active. That's probably caused by the two different screens. So it's not recommended to use DOnoColorMapping in such a case. Maybe, I will just have to set "the icons screen" early enough?

[Michael]

Originally Posted by PeterK

Can't reproduce that "bug" under WB 3.9, not even when WB 3.9 an DOpus5 are running at the same time. Is that with WB 3.1 ?

Ok, it seems to have some side effects when WB and DOpus5 are both active. That's probably caused by the two different screens. So it's not recommended to use DOnoColorMapping in such a case. Maybe, I will just have to set "the icons screen" early enough?

The bug appears if WB is run after DO inWBmode on the same screen.
If running WB first and then DO on same screen, then the bug is not present.
Also interesting, if I do an icon reset in DO, then all disk icons get proper alternative images when selected as if DOnoRemap patch was not active.
Other icons get the shadow mask.

[PeterK]

Update to icon.library 46.4.394:

All the odd side effects, which occured when both, the WB and DOpus5 were running at the same time, should be fixed now, as I hope.

Futhermore, this version always disables the colormapping for the first icon image on Hi/Truecolor screens (also on WB 3.0/3.1), which should give half of the speed gain that can be achieved with the DOnoColorMapping option. The only known bug that I can't fix appears when you drag & drop a new image into the Icon-Info tool of DOpus5. The first image stays invisible until you save the icon to disk. (I can live with this issue)

[Michael]

Writing this for the third time, bugger eab cache/reply what ever that looses what was typed

Nice update, but I am not happy, since DO IconInfo is not working 100% as it was by defaulut in 393.

Speed improvement again, yes!

Crystal v393 - 7.200s v v394 - 5.600s (with DOnoRemap was 4.696, now 4.720s)
Kens v393 - 16.360s v v394 - 15.140s (with DOnoRemap was 14.120, now 14.600s)

Strange ?

Will add more info and Q's soon.

[Michael]

DO IconInfo is a puzzle. Until it is behaving properly, the current icon.lib behaviour should be optional. In other words I prefer eye candy when it works 100% v speed gain and some problems.

Regarding the problem. I have noticed that only the first image of 3.5 icon is missing when you D&D copy it. The selected image is there!
Also if you D&D a classic planar icon, all images are working.
Further more, if you do a few D&D, then sometimes you can even get the first image of 3.5 icon to display! Very odd, but there is something in it.

Further more, DO somehow know when you drag a fake def icon to the IconInfo, since it prevents you from doing so. That means that it knows something about the type of icon, and maybe there is a chance to add 50% transparency to def icons in DO too like in WB. Of course it is probably better to do it in DO open source project itself.

[Michael]

I have raised the question on pen handling before, but really have to get back to it.
On 15/16 bit screens I think there is something wrong with the way the pens are allocated.
eg. old OS icon.libs allocate less pens then your current implementation, in my case (for SYS:Prefs) a good 40+ pens less.
Personally I can't see any difference between the images/colour remapping between them.
Anybody know a way how to compare pixel by pixel two images for diffs?
So what me wonders is how the colour precision / pen allocation works on 15/16 bit screen? What happens to close colours like 254,254,254 and 253,253,253 ? Are they allocated as 2 pens or united as one ?
On the 16 bit display it's the same colour 255,255,255 (or 31,63,31 in 16bit values) so even more close colours are still the same colour, since the tolerance is +/- 4 units for RED/BLUE and +/- 2 for GREEN. This makes 256 shades the same colour, and even 512 for 15 bit screens.

UPDATE:
Done some more experiment....
Old lib produces 120 unique colours for icons in my sysrefs
v394 produces 251 unique colours for same icons

Closer examination shows that some colours shift from their original icon colour.
Old lib allows bigger colour shifts, v394 is streakier and closer to original colour and thus requires more colours.
eg. for old lib only one pen was used once, the others have a larger used count.
while v394 has about 40 pens used for single pixels, and another 40 with a count below 5 pixels.

So then, can we have this behaviour made configurable ?

[PeterK]

Update to icon.library 46.4.395:

Fresh for your bash !!

This version fixes the problems with DOpus5 Icon-Info and it's really a lot faster than everything before. DOpus5 is nearly as fast as the Workbench now.

Please, tell me about any conflicts that you get with this update, because I didn't have much time to test it yet.

@Michael
Sorry, but I have no intentions to care about the missing pens in DOpus5. If I can find the reason accidentally then I will try to fix it, of course.

[Retrofan]

I would like to tell about Speed tests, but (it must be just me) they always seem random to me with WinUAE and OpenWin.

[Michael]

Had a quick go on my old uae based copy of my system (around 2000) at work. and it works amazing! Hopefully I will report how it works on my real system this evening.

What's worse, now I have to find out what's causing problems with DO free pens not getting released. Do you have the same problem ?

What shocked me, is under my old uae based system the pens get released in DO!
I hope it's not related to P96/CGX difference. Since fixing that is close to impossible these days. So I don't know, are these good or bad news?

[Michael]

Originally Posted by Retrofan

I would like to tell about Speed tests, but (it must be just me) they always seem random to me with WinUAE and OpenWin.

You have to make sure UAE is running with constant cpu resources, then it will be more or less stable in performance.