Another day, another component: Graphics.
There is not much new about graphics. There are two old bugs we found, namely when attempting to render VSprites on a NULL ViewPort which caused MuForce hits. It seems unlikely that this happens, but there are a couple of games that load their own view by LoadView(NULL). If, at that point, you are still holding an icon on the workbench - happens quite easily by an erratic mouse button - and then quit the game, the workbench is already continuing to move the icon even though the graphics view is not yet loaded. The gels functions have been updated to handle this case now gracefully.
There is also some news on AllocBitMap() and RTG support. AllocBitMap() has been enhanced a little bit to use its "friend bitmap" pointer differently in case a specific "flag" combination is set. In such a case, the "friend bitmap" becomes a taglist, and carries information such on the display ID. Previous versions of the operating system act gracefully on this flag combination and return NULL, i.e. fail the allocation.
Now, why is this important? Consider an RTG graphics scheme where a software needs to open a screen in a non-native graphics mode. At this point, there is no "friend bitmap" because the screen is not yet open, yet the system calls into AllocBitmap() for the screen. AllocBitMap() is now patched over by the RTG software, and is supposed to take the bitmap to the graphics RAM of the RTG board. Unfortunately, it cannot really know as there has not been an indicator on AllocBitMap() where the screen is supposed to go, and which graphics mode it is going to be.
P96, at least, "went fishing": It looked at the stack frame from the call, used a heuristics, and if the heuristics said that the call is likely coming from intuition, it checked the stack frame for the display ID where it was laying around - by pure chance, not by design - and then used the display ID from there.
Of course, this is not a robust algorithm, and as the stack layout changed with intuition V45 as it was recompiled by another compiler, P96 would have been broken. So V45 of intuition contains a special "kludge", a short piece of assembler stub, that prepares a stack frame within OpenScreen() that looks like the one from V40, and then called into AllocBitMap() to make P96 happy.
Needless to say, this is all a fragile design and need to go, and so it does now. Intuition v47 (more to be said about this) uses now the new AllocBitMap() interface with tags prepared to list the display ID, and the latest P96 versions (2.3 and up) grab the displayID now through the new interface. Actually, this interface was already put into P96 years ago (around ~2000 or so), but wasn't activated as its counterpart in intuition and graphics was missing. Not any more.
It is likely that cgfx requires a similar kludge, probably for additional functions, but we don't know what exactly, and Frank hasn't reacted on the request to document them, so users of CGfx wil have to downgrade intuition to v40. Just put it in LIBS: and System-Startup will pick it up there. No need for reboot, but no new intuition functions either.