I've experienced a minor glitch when using P96's rtg.library > 42.1106 (26-Dic-2021) (this was the last one without this issue)...
My WinUAE sys (Zorro III RTG + p96, 060 with 3.9 and mmulib by T. Richter etc.):
icon.library 46.4.563 Aminet - util/libs/IconLib_46.4.lha
Picasso96API.library 2.407 (27-Feb-2022)
emulation.library 41.493 (27-Feb-2022)
rtg.library 42.1226 (27-Feb-2022)
©1991-99 A.Kneer T.Abt, ©2017-2018 icomp
When loading Coloricons >32colors with PPaint (reproducible also with free version from Aminet) + pio_ico plugin Aminet - gfx/ppaint/pio_icon.lha right after loading the icon PPaint screen palette gets corrupt, as discussed on EAB forum icon.library 46.4 test versions - Page 196 - English Amiga Board (abime.net) :
1. launch PPaint
2. open 'Load brush' PP-requester
3. double click on the right: ICON format (will open pio_ico prefs), and then Cancel
4. at this point, from WB, drag'n'drop a program with coloricon >=32colors on PPaint app-icon, this will automatically point to the correct path into previously open PPaint 'Load brush' requester
5. switch back to PPaint and just load the program (it has an .info of course that will be automatically loaded)
You'll see the screen palette gets altered (PPaint UI turns blue!) in the video after loading, and to restore the correct palette I can simply switch screens back and forth from usual Intuition depth screen gadget in the upper-right.
The author of new icon.library commented:
This rtg.library palette issue seems to occur only when you have at least two different screens open, like WB in TrueColor and another 8-bit screen in chunky mode. It is triggered by SetRGB32() and ReleasePen() and it seems to happen when colors of a non-active screen should be changed (for the first time). My icon.library tries to do that with the delayed color mapping. There is no problem with my direct access to the private data structure of PalExtra as I expected. I can still allocate new free pens and increase the reference counters as usual, if I just disable the call to SetRGB32(), then everthing still works, except that I don't get the desired new colors, so a few pixels show wrong colors, but the screen palette and DOpus5 wallpapers won't get corrupted.