Mmm ok, aniway are you registered to the Hyperion forum ?
If not please do it, so eventualy we can continue our conversation there, and there is an good possibility to have a talk with the OS4 team
Let's see if anyone can help. Maybe I can at least implement partial overlay support for OS4, i.e. overlay support for normal video playback. When clipping is needed, I could revert to the software renderer. But I'm still not sure if it's possible because all those Picasso96 PIP stuff is quite a nightmarish design IMHO.
airsoftsoftwair wrote:Let's see if anyone can help. Maybe I can at least implement partial overlay support for OS4, i.e. overlay support for normal video playback. When clipping is needed, I could revert to the software renderer. But I'm still not sure if it's possible because all those Picasso96 PIP stuff is quite a nightmarish design IMHO.
Yes It would be good atleast for having somethings better ... aniway as you say let's see if they can help you
This sums up pretty much the dilemma OS4 is in nowadays. All the people who know something about the internals of certain APIs seem to have vanished completely. I had the same problem when adding AmiDock support in Hollywood. It was a real nightmare to figure out how this is actually supposed to work. I certainly won't go to such pains for overlay support again. So I'm afraid that the odds are rather against overlay support in Hollywood because there seem to be no more people around who know something about Picasso96 PIP windows and the so called core developers don't have access to all the source codes so they can't check.
Yep i saw, but probably because they are busy with many other unrelated things ... but don't worry as this is an essential feature for me, and as i know who can work on it be sure that i will remind them from time to time ... so courage and be patience
Just for fun i've asked ChatGPT and here is the answer:
1. The "Parenting" Problem
In the classic AmigaOS API, windows are independent. Even if you use the RTG extensions for PIP, the system doesn't know that the video window "belongs" to the GUI window. If you move the parent window, the coordinate of the PIP overlay remains fixed relative to the screen (or the graphics card bitmap).
2. The solution (the only possible one)
You actually have to manually manage the movement, but there are ways to make it less "ugly":
IDCMP_CHANGEWINDOW: This is the correct event to monitor. Every time the main window is moved, you must recalculate the PIP coordinates and call the PIP layer update function (usually via driver-specific functions or p96PIP_SetAttrs).
Silent Refresh: Although it may seem inelegant, if the code is optimized and the JIT (Petunia) or native PPC code is fast, the movement appears smooth. The visual "delay" between the window and the video is minimal on Radeon 9xxx cards.
In summary for your case (Radeon 9xxx):
Yes, you must manually handle the IDCMP_CHANGEWINDOW message.
To minimize the "jerking" effect, be sure to:
Disable hard GUI refresh during navigation.
Update the PIP coordinates at the exact moment you receive the position change message.
Here's a conceptual example in C for AmigaOS 4.1. Since the system doesn't offer automatic parenting for PIP (Picture-in-Picture) layers on Radeon 9xxx, the only way is to intercept the main window's move event and update the PIP coordinates accordingly.
The example assumes you're using the Picasso96 (P96) API, which handles PIP on OS4
while ((msg = (struct IntuiMessage *)GetMsg(mainWin->UserPort))) {
uint32 class = msg->Class;
switch (class) {
case IDCMP_CLOSEWINDOW:
running = FALSE;
break;
case IDCMP_CHANGEWINDOW:
case IDCMP_MOUSEMOVE:
/*
Quando la finestra genitore si muove, ricalcoliamo
la posizione del PIP basandoci sulle nuove coordinate
LeftEdge e TopEdge della finestra.
*/
if (pipObj) {
// Offset relativo (es: il video sta a 10px dal bordo)
int32 newX = mainWin->LeftEdge + 10;
int32 newY = mainWin->TopEdge + 20;
// Aggiorna la posizione del layer PIP in tempo reale
p96PIP_SetAttrs(pipObj,
P96PIP_Left, newX,
P96PIP_Top, newY,
TAG_DONE);
}
break;
}
ReplyMsg((struct Message *)msg);
}
}
}
-----
Implementation Key Points:
IDCMP_CHANGEWINDOW: This is the fundamental signal. It is sent when the user releases the window or during movement (if opaque drag is active).
p96PIP_SetAttrs: This function is very efficient. On a Radeon 9250 with AmigaOS 4.1, moving the hardware overlay is almost instantaneous.
Relative Coordinates: The PIP lives in screen space (Screen coordinates), while your GUI lives inside the window. You should always add mainWin->LeftEdge and mainWin->TopEdge to maintain alignment.
Synchronization: If you notice lag (the video follows the window with a delay), make sure your window has the WFLG_REPORTMOUSE flag enabled to receive more frequent updates during dragging.