icon.library 46.4 test versions

[bladecgn]

Originally Posted by PeterK

Update to icon.library 46.4.350:

The icon ghosting was never available on WB v44+ without a gfx-card driver and the cybergraphics.library loaded into memory when an AGA screenmode was selected.

Thank you very much Peter. Incredibly quick fix. That totally solved the problem (also on my genuine Amiga 1200).

[Michael]

I have always wondered how to test FixCGX ReadPixelArray patch ?
What is known not to work without it ?
Or does it effect some speed tests ?
Or is it pointless nowadays ?

[PeterK]

The bug in the CGX ReadPixelArray() function is it not to preserve the contents of the data register D2.

The fix saves D2 on the stack, calls ReadPixelArray() and finally restores D2 from the stack. That's all.

But of course, you don't need this fix for the icon.library, because it's built-in.

I don't know if there is any other program, tool, lib or whatever which would require this fix. Not every program that is calling ReadPixelArray() will need the contents of D2 after the function call again. The fix is a bonus for CGX-users and not for IconLib-users.

[PeterK]

Update to icon.library 46.4.352:

It was really not my intention to come with some new bugfixes so soon after the Aminet release, but then I got a bug report from a user at A1k.org and I also found another bug myself. There was a problem in the zlib decoder with some very large icons. The second problem was the slow icon updating after using snapshot on WB 3.0/3.1, because all selected icons were drawn again and again for each of them. I've removed the WB notification to make this faster now. And the last bug was a crashing WB menu with the 68000 version on 256 color screenmodes (8 bitplanes). This was probably caused by zero page accesses, which I thought would be harmless, but Intuition didn't like them.

[Michael]

Originally Posted by PeterK

The bug in the CGX ReadPixelArray() function is it not to preserve the contents of the data register D2.

The fix saves D2 on the stack, calls ReadPixelArray() and finally restores D2 from the stack. That's all.

But of course, you don't need this fix for the icon.library, because it's built-in.

I don't know if there is any other program, tool, lib or whatever which would require this fix. Not every program that is calling ReadPixelArray() will need the contents of D2 after the function call again. The fix is a bonus for CGX-users and not for IconLib-users.

Very detailed and interesting info. But I still can't sleep without knowing where to reproduce the bug, so that there is a need for it's permanent install. Or as I have understood correctly, it is part of the icon lib? So there is no need to install it independently?

[Retrofan]

Peter have you got any idea about the graphic corruption of the icons on the MUI beta preferences? http://eab.abime.net/showpost.php?p=962421&postcount=10

[PeterK]

Originally Posted by Michael

Or as I have understood correctly, it is part of the icon lib? So there is no need to install it independently?

No, the built-in CGX-fix just protects the internal direct drawing function from crashing with the icon.library.

As I said, this fix is for CGX users. They should only install it in case that there are any applications, tools or whatever crashing or freezing their system for unknown reason. Since no requester will pop up and say "This is the ReadPixelArray() bug !" the CGX users can only give my fix a try to see if it helps.

@Retrofan
Up to now, I didn't care about the new MUI beta version. Maybe, I will try it out if I have some time for experiments. No promise, no priority! Sorry. Update: my answer can be found in your MUI 3.9 thread.


Update to icon.library 46.4.353:

Removed the TagItem for the WB-Update notification completely from the PutIcon() function, which is used by WB 3.0/3.1 only. Found another bug which appeared when icons were dragged and copied into another drawer on WB 3.0/3.1: "Object of wrong type". Should be fixed now.

[Bamiga2002]

Thnx for continuous updates. 'Tis installed and testing as I use my miggy (which has been a smaller priority atm...)

[PeterK]

Thanks Bamiga2002

Update to icon.library 46.4.355:

Since Aminet jams and is blocking new updates atm, I've added a complete release to the attachment here this time.

 Latest changes for this final version rc2:b
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Optimized the memory allocation and release using freelists.

A bugfix in the zlib decoder avoids crashes with large icons.

The PutIcon() function for WB 3.0/3.1 won't add the TagItem
NotifyWorkbench anymore for a faster WB-update with snapshot.

A fix for the 68000 version solves crashes of the WB-menu or
intuition occurring with 256 color screenmodes = 8 bitplanes.

Another fix to prevent "object of wrong type" with icon copy.

[ancalimon]

Originally Posted by PeterK

Some additional information concering the icon.library:

How to use LoadResident with icon.library and workbench.library and save 200 kB FastMem ?

There is a problem with SetPatch which does not realize that LoadResident has already loaded these libraries into memory, although the same procedure seems to work perfectly with LoadModule. But it does not !

SetPatch needs the option DISABLEROMMODULES ""
For example: SetPatch QUIET SKIPROMMODULES scsi.device DISABLEROMMODULES ""
Add the following lines or something similar to your startup-sequence:

 
C:Version >NIL: exec.library 45
If WARN
   C:LoadResident >NIL: LIBS:icon.library
   C:LoadResident >NIL: LIBS:workbench.library
EndIf

C:SetPatch QUIET DISABLEROMMODULES "" ; plus other options like SKIPROMMODULES ....

How to use LoadModule with icon.library and workbench.library ?

Although it seems to work for LoadModule without this trick, I've checked it out and ...
surprise, surprise, you can save about 180 kByte FastMem even with LoadModule, but LoadResident is even better in saving FastMem, it needs nearly no extra FastMem at all. Add something like this to your startup-sequence:

C:LoadModule >NIL: LIBS:icon.library LIBS:workbench.library NOREBOOT
C:SetPatch QUIET DISABLEROMMODULES "" ; plus other options like SKIPROMMODULES ....


Something else: Important for users of DOpus Magellan II:

Make sure that the newicon.library V44 is installed in your LIBS: drawer.
And activate "Smart Icon Copying" under the DOpus "Icon Settings".

Would
Setpatch SKIPROMUPDATES QUIET
also work without problems?

I'm using everything with Blizkick with a huge extresbuf instead of loadmodule.

[PeterK]

So, you are loading the icon.library and the workbench.library already resident with Blizkick, right ?

I don't know how SetPatch v44 reacts when it finds these libs resident in memory loaded by Blizkick, because I have only WinUAE for tests.

The SetPatch options SKIPROMUPDATES or SKIPROMMODULES have no effect concerning the icon.library or the workbench.library, since these two libs don't belong to the contents of the "Devs:AmigaOS ROM Update". You can only SKIP MODULES which are located inside of this file. But the icon.library and the workbench.library are loaded from Libs: by SetPatch v44 if they exist there. And that can only be avoided by removing or renaming them or by using SetPatch DISABLEROMMODULES "" . The empty string is an important argument. Of course, you can also add other options, for example:

SetPatch DISABLEROMMODULES "" SKIPROMMODULES ram-handler,shell,console.device,scsi.device QUIET

If you want to know whether SetPatch has loaded these libs a second time then type "Avail" into a shell directly after booting up to WB has finished, once with the option DISABLEROMMODULES "" and then without it in your startup-sequence.

[mfilos]

Thx a lot Peter for your continuous efforts into making this a rock stable library!
I can't express enough my appreciation.

\o/

[PeterK]

Originally Posted by mfilos

...this a rock stable library!

I really wish it were rock stable and bug free, but it's not.

The last days, I found so many small bugs that it's a shame to be the author of this piece of crap

Ok, I've fixed these bugs, but then I've new ideas to improve the library and you can be sure, writing new code like last night will introduce new bugs again (that's the way of life for a drunken coder like me)

However, thanks for your motivation, mfilos

[Toni Wilen]

Originally Posted by PeterK

I don't know how SetPatch v44 reacts when it finds these libs resident in memory loaded by Blizkick, because I have only WinUAE for tests.

Blizkick works with WinUAE if "MapROM emulation" checkbox in ROM panel is ticked.

[PeterK]

Oh NOOO, I can't believe it...
What a bullsh.t, because that means I have to care about yet another possible configuration when testing my lib instead of having an excuse. And I already feel so tired doing all these boring tests over and over again

Nevertheless, thanks a lot for making all these options available, Toni
It's absolute fantastic what huge number of features WinUAE is capable to offer meanwhile !

[ascp]

Fantastic work PeterK.
Are you thinking about doing any other libraries too, after this one?

[PeterK]

Thanks jonathan, but I've no plans for any new projects yet.


Update to icon.library 46.4.356 and 46.4.357:

Reworked the PutIcon() function for WB 3.0/3.1 icon snapshot again. Now, it should avoid all unnecessary icon redrawing caused by the "WorkbenchNotification" tag whenever possible. Window=>Snaphot=>All will be done faster, too.

[Lonewolf10]

Originally Posted by jonathan

Fantastic work PeterK.
Are you thinking about doing any other libraries too, after this one?

Perhaps he should go on holiday first?

There's nothing I hate more than to finish a long coding project (6+ months) and then dive straight into another big project. I usually have atleast a 1 month break before starting something new

[PeterK]

No, I can't go on holiday anymore, since my health condition is very poor for many years already. I stopped working end of 1998 and the last five years I did not even leave the house where live. The end of the project will be the final. Nothing comes next...

[Retrofan]

Sorry to hear that mate. Thanks a lot for your hard work is the least I can say. AmiKit Real woudn't had started without this marvellous library. Anyhow leave any update if you feel you are wasting your valuable time, but keep on as long as you can.