DoHookClipRects(): How to draw LAYERSMART obsured parts with correct offset ? ->Corrected, cause was wrong process .
I have a very perverse glitch when using a DoHookClipRects() draw hook, to render my glyphs with utf8rastport, my lib to render texts and emojis.
The bug happen OS3.2.3 UAE P96.)
I have to use that function in P96/CGX RTG modes where I need to blend directly RGBA pixels with the CPU on the screen bitmap.
The hook is meant to have this struct passed to a1:
struct bf_msg {
struct Layer *bf_Layer;
struct Rectangle bf_Bounds;
LONG bf_OffsetX;
LONG bf_OffsetY;
};
In the hook, I apply the rastport top-left origin offset to the drawing. I get it with msg->bf_Layer->bounds.MinX /MinY
...then I add that to the bitmap, clip to msg->bf_bounds, and draw:
It works perfectly for the "rectangle parts" that are visible, but I have a boopsi LAYERSMART window, and it looks like
it also calls the same hook for the "backup rectangle" that are obscured by other windows in front, and in that case the offset given with msg->bf_Layer->bounds.MinX/Y is wrong, and of course because it's an hidden part of the rectangle, so it shouldn't even been written on the screen bitmap, but well when you move the window that obscure the part, the part that was hidden is refreshed with "an offset error", like if msg->bf_Layer->bounds was applied 2 times...
So it looks like In the hook draw function I have to test if I have to draw on an "obscured" window part , and not apply the offset, or the same offset, in that case... brrrr something like that, no idea.
code in urp_cgx_clip_hook_func(), https://github.com/krabobmkd/EmojiGear/blob/main/libutf8rastport/utf8ra… , l. 1742.
By the way, I can't find a single example of a hook function to be used with DoHookClipRects() on the whole planet
By the way, I can't find a single example of a hook function to be used with DoHookClipRects() on the whole planet
TTEngine sources on Aminet, "lib.c" file, render_hook() is the hook, render() calls it with DoHookClipRects().
yes, good find... and also the NDK3.2 has actual example of doing a legitimate "BackFill hook" ...
That said, the problem I have actually only happens with my UAE P96 driver (recent indiv.comp/ P96 + antique UAE driver)... and bug does not happen with my pistorm P96 indiv.comp + recent p96 driver... So it may be "P96 bug related", but as I see no other graphics.library draw call having the bug on UAE, I'm just disappointed about this. ( could be a bug on my part , or on P96 part, or the UAE p96 driver part.) ... So well if works on my A1200 pistorm: fine. "I TRIED".
Also I understand close to 0% of what is happening when you draw a rastport with DrawHook or whatever BlitBitmapRastport with LAYERSMART, does it draw the obscured part "somewhere else" ? No draw call can be done from your part when you remove the obscuring window, so it would repair, and there is no superbitmap thing in that mode... strangestest.
... So finally corrected, but my draw hook code was correct. And so just so you know, the repair of the background when you remove an obscuring window is done by "another process at any time" (I was wondering)... and basically for that gadget I'm forbidden to render under any other process than my main process... and somewhat that triggers that "offset bug." so what I do in the rendering function now, to correct this, is :
if( FindTask(NULL) != myOwnProcess )
{
signal myOwnProcess to render later, by asking a refresh.
} else
{
render for real
}
... I already did something similar with "all my other GM_RENDER" , expect the one that was bugging... of coooourse.
Online Status
To clarify again, the wrong offset happens when:
1. there is a part of the window that is obsured
2. I refresh the drawing, with a resize, but I keep the window behind.
3. then I move the window in front that obscure parts, and the part behind is restaured wrong.