Or it needit src/dest in any case even for querying hardware support ?
You need source and destination bitmaps. Ideally, the destination would be locked to the target graphics card too, for dual graphics card systems. Otherwise the graphics library might just move the bitmaps to a different card.
I'm trying to merge this with the other patches using git. There are some compiler warnings:
1) Rect k used uninitialized (declared near 3787)
2) Arithmetic on void pointer (near 4234). These "APTR pY, pCb, pCr;" should be declared as "uint8 *".
Checked your compositing-ami603-kas1e branch. And yeah! It works same as for us, just without CGX, cool! Through found few moments:
1). Where things should be "black" (on the borders of the window when resized, they now not cleaned and keep show previous content. That something about fillrect i assume and color_key / value spend too. Maybe it just difference between FillPixelArray from CGX5, and RectFillColor from graphics.library ? Will check with CGX5's FillPixelArray if it make difference indeed.
2) Found that in latest commit you overwrite WritePixelArraysAlpha() functions with wrong ones (not in owbbrowserclass, but in other files), while should keep just WritePixelArraysAlpha as in original , as it now implemented in os4funcs.cpp, etc. Not big deal, as it just branch about compositing, but still to not traps with issues later if use that branch :)
Also, i not sure, but do need all that "vertex" stuff in compositeHookFunc() what you think ? Hans says before we didn't need that.
Edited by kas1e on 2020/3/30 12:16:53 Edited by kas1e on 2020/3/30 12:18:14
The vertex stuff was used because in my experience i had lots of trouble when using the SrcWidth, SrcHeight, scale stuff, and with vertex you don't need to bother with scalex/y calculations etc. Feel free to change it if you think the code is clearer.
@Ami603 Ah, ok , got it. Then probabaly better to keep it as it. Now only to understand why when we switch to another tab video continue to be played in new tabs instead of keeps out in tab when it open.
Checked your compositing-ami603-kas1e branch. And yeah! It works same as for us, just without CGX, cool! Through found few moments:
Some things went wrong during merge...
I reset git history approximately to the point where you started your patch, and then tried to merge the newer patches on top of that, fixing the conflicts.
Quote:
1). Where things should be "black" (on the borders of the window when resized, they now not cleaned and keep show previous content. That something about fillrect i assume and color_key / value spend too. Maybe it just difference between FillPixelArray from CGX5, and RectFillColor from graphics.library ? Will check with CGX5's FillPixelArray if it make difference indeed.
Does this happen only with my branch? Can you see which merge failed?
Quote:
2) Found that in latest commit you overwrite WritePixelArraysAlpha() functions with wrong ones (not in owbbrowserclass, but in other files), while should keep just WritePixelArraysAlpha as in original , as it now implemented in os4funcs.cpp, etc. Not big deal, as it just branch about compositing, but still to not traps with issues later if use that branch :)
Yes, this one I noticed only after git push :( This should be simple to fix though. My bad totally.
PS. some of the new compiler warnings are still not fixed.
Does this happen only with my branch? Can you see which merge failed?
I added now for a test back CGX5's FillPixelArray() instead of graphics's library RectFillColor() in 2 places : and have borders be black again.
So it seems that RectFillColor() or works differently, or have bug in terms of applying that "0x000000" part, or some bug somewhere else we had now (maybe something with _rp(obj) part or so ?). I even tried to replace 0x00000000 on 0xFFFFFFFF just in case for RectFillColor, but that change nothing too.
In other words simple doing this:
/* draw rects, if visible */
if (data->video_x_offset || data->video_y_offset)
{
if (IsValidRect(&b1))
{
/*RectFillColor*/FillPixelArray(_rp(obj), b1.MinX, b1.MinY,
b1.MaxX - b1.MinX + 1, b1.MaxY - b1.MinY + 1,
0x00000000);
}
(with commenting out all other CGX functions in their includes, and using graphics.library ones for all other parts, but only use FillPixelArray from CGX) , make black borders be there.
@Capehill Yeah, Ami603 help with as well, so now all fine.
@Capehill,Ami603 Now probabaly i can remove ifdefs, check that all ok , and commit it. And then on top of that we will need to fix checking on compositing and fallback to how it was without, and find out how to fix issue with Tabs and that all. Everyone agree ?:)
if (IsValidRect(&k))
{
RectFillColor(_rp(obj), data->rect.MinX, data->rect.MinY,
data->rect.MaxX + 1, data->rect.MaxY + 1,
0xFF000000); // we don't need color key for compositing
@Capehill Tried with Ami603 today all kind of stuff, but still can't get why video in fullscreen mode renders-copy to the new tabs. And only video. Buttons, all those borders-fillrects are where they should be: in the video tab, but video itself renders to all the newly opened tabs.
Its probabaly something at the begining of DEFSMETHOD(OWBBrowser_VideoBlit), where we do "if(msg->src && msg->stride && lock != NULL)".
Originally for morphos it was "if(data->video_handle && msg->src && msg->stride && LockVLayer(data->video_handle))", but not sure if that the only enough to detect if we have active tab with video or not.
We should't blit if the tab not active, but how it works originally for mos i can't get. Maybe that "data->video_handle" value somehow make difference, or that its LockVLayer called and fail/not-fail when tab active/notactive, dunno. Maybe some ifdefs borks somewhere, or "if compositing==1" checks.
Some news : right now after lot of check Ami603 was able to fix issues with "video renders in another tab". Now we fighting with issues that on peg2 we crashes, as didn't check properly on if compositing available, dealing with it now.
Quote:
On MorphOS, does the video keep on playing on a background tab (is there sound?), also does it stay in fullscreen or not?
Yes and yes. For us its the same now.
Quote:
I'm trying to figure out should there be an exit from this fullscreen mode, or not.
If you mean "iconify" then on morphos after we iconify and de-iconify back, it then swith to window mode, yes.
In other words, i hope today we will deal why it crashes on peg2, then i will made a commit + beta05, and since that one we can start dealing with little bugs if we will have any.
Good news, is that in compare with CGX5 on morphos, we can have many videos played in different tabs. Not just one overlay one , but many. I tried now just open 3 tabs, 3 different videos and hit them all to fullscreen : works !:) Just that damn "exclusive ahi" kill the fun, as if mediaplayer works, no other sound/music from anything else (even from another instanses of mediaplayer" will work. But that probabaly can be deal with later.
Well no beta today, hope tomorrow. Issue we find now, is that something seems wrong with return values of compositetags call when we call it on hardware which not support composite-video, but when our call are with "verticies".
And while Without "verticies" we have not crash on cards with no-compositing, we have no rendering on cards with compositing :) So that need to be deal with.
In Hans De Ruiter CompositeYUV.c example, there is a code that checks for compositeavail or not:
// Test if composited video is available
uint32 fillWindowWithBitMap(struct BitMap *bitMap, struct Window *window)
{
// Need to composite onto the window's rastport. Since CompositeTags() only renders to bitmaps,
// we use ILayers->DoHookClipRects().
CompositeHookData hookData;
struct Rectangle rect;
struct Hook hook;
// Vertex 2 top right coordinates
vertices[1].x = hookData->right;
vertices[1].y = hookData->top;
vertices[1].s = hookData->srcWidth; // width of the image to blit. for now global
vertices[1].t = 0.0f;
vertices[1].w = 1.0f;
Then it works on x5000 as expected, and while it return on pegasos2 "operation would fall back to software emulation" it then instead of rendering nothing, just crashes once i move window. But should not crashes.
Rather annoying that the old drivers don't handle the vertex arrays case properly, and return the error code.
Your code is missing some tags you need when using regular "rectangle mode." You need the following tags too: COMPTAG_SrcWidth COMPTAG_SrcHeight COMPTAG_OffsetX COMPTAG_OffsetY
One small gotcha with CompositeTags(), is that COMPTAG_DestX|Y|Width|Height define a clipping rectangle rather than where the bitmap will be rendered. That's why you need to set COMPTAG_OffsetX|Y too.
While that may seem unnecessarily complicated, it's pretty handy when you use DoHookClipRects(). You set the clip rectangle to the clip region, and COMPTAG_OffsetX|Y marks where the target draw region is.