Login
Username:

Password:

Remember me



Lost Password?

Register now!

Sections

Who's Online
69 user(s) are online (51 user(s) are browsing Forums)

Members: 0
Guests: 69

more...

Support us!

Recent OS4 Files
OS4Depot.net




« 1 2 3 4 (5) 6 7 8 ... 15 »


Re: Odyssey's MediaPlayer thread
Home away from home
Joined:
2007/9/11 12:31
From Russia
Posts: 6325
@Capehill

Quote:

It seems that there isn't that much CGX usage after all? Most of it is in the browser class and that's dealt more or less? Started another branch which mostly removes the CGX use: https://github.com/capehill/Odyssey/tree/use-graphics-library (needs review)

I have some doubt regarding WritePixelArrayAlpha, not sure how exactly the global alpha is applied: https://aros.sourceforge.io/documentat ... elopers/autodocs/cgfx.php

So there might be some visual issues but maybe CompositeTags can be used in case alpha blending is needed.


Checked, and while it seems to work, its indeed in favicons/etc we don't have alpha channel, see how it looks like :

(press open in new tab)

Resized Image

See "compas" didn't have alpha, all the favicons in fast links also have black areas, and in url-bar histroy as well. So its transferanimclass.cpp, faviconclass.cpp and all the stuff where we replace WritePixelArrayAlpha() on WritePixelArray().

As for replace it with CompositeTags() : will it works everywhere as it now with CGX's WritePixelArrayAlpha ? Or it will be left out some machines with very old graphics cards, etc ?

Oh, i found custom implementatin of WritePixelArrayAlpha for os4 : that one done by Thore for MUI and for MUI classes. Check this out:

https://github.com/amiga-mui/nlist/blo ... cc/WritePixelArrayAlpha.c

Probabaly we can just reuse that one in os4funcs.cpp and it will works everywhere as before. What you think ? It through have some includes for CGX , but i think they can be removed with replacing ReadPixelArray() and WritePixelArray() if need it.


Edited by kas1e on 2020/3/28 7:30:33
Edited by kas1e on 2020/3/28 9:31:33
Edited by kas1e on 2020/3/28 9:32:53
Edited by kas1e on 2020/3/28 9:33:54
Edited by kas1e on 2020/3/28 9:37:02
Edited by kas1e on 2020/3/28 9:38:11
   Report Go to top

Re: Odyssey's MediaPlayer thread
Quite a regular
Joined:
2008/10/29 10:20
From Uppsala, Sweden
Posts: 749
@ktadd

Thanks!

@kas1e
Can you add the paypal options in the first post in this thread? Its easier to find.

   Report Go to top

Re: Odyssey's MediaPlayer thread
Home away from home
Joined:
2006/11/20 16:26
From Norway
Posts: 2793
@kas1e

I believe the problem is on old voodoo cards, picasso cards. The radeon 7250 / 9250 should handle it. And I will guess that CompositionTags might not work on 8bit screen modes.

There is a software patch for CompositionTags on OS4Depot, it was designed for WinUAE users, so peaple who do not have it can use that. (as long as its only ARGB, YUV422 needs HD cards)

Another option is simple make it a function pointer, then you just swap out the routine, if you have right graphic card.
It should be possible to check if the graphic display has composition support or not.

   Report Go to top

Re: Odyssey's MediaPlayer thread
Just can't stay away
Joined:
2007/7/14 21:30
From Lothric
Posts: 1069
@kas1e

CompositeTags approach requires an extra bitmap located in VRAM so it would need also a wrapper function to replace WritePixelArrayAlpha functionality.

If the code you found works (and I suppose we can use LGPL as also many other parts of the project are LGPL) then maybe it can be used.

   Report Go to top

Re: Odyssey's MediaPlayer thread
Home away from home
Joined:
2007/9/11 12:31
From Russia
Posts: 6325
@Capehill

So i come up with that :

#include <proto/exec.h>
#include <proto/graphics.h>

#define AllocVecShared(size, flags)  AllocVecTags((size), AVT_Type, MEMF_SHARED, AVT_Lock, FALSE, ((flags)&MEMF_CLEAR) ? AVT_ClearWithValue : TAG_IGNORE, 0, TAG_DONE)

static LONG do_alpha(LONG aLONG v)
{
  
LONG tmp  = (a*v);
  return ((
tmp<<8) + tmp 32768)>>16;
}

ULONG _WPAA(APTR srcUWORD srcxUWORD srcyUWORD srcmodstruct RastPort *rpUWORD destxUWORD destyUWORD widthUWORD heightULONG globalalpha)
{
  
ULONG pixels 0;

  if(
width && height 0)
  {
    
ULONG *buf;

    if((
buf AllocVecShared(width 4MEMF_ANY)) != NULL)
    {
      
ULONG xy;

      
// Incorrect but cant bother with alpha channel math for now
      
globalalpha 255 - (globalalpha >> 24);

      for(
0heighty++)
      {
        
ULONG *spix;
        
ULONG *dpix;

        
//ReadPixelArray(buf, 0, 0, width * 4, rp, destx, desty + y, width, 1, RECTFMT_ARGB);
        
ReadPixelArray(rpdestxdesty y, (uint8 *)buf00width 4PIXF_A8R8G8B8width1);
        

        
spix = (ULONG *)((ULONG)src + (srcy y) * srcmod srcx sizeof(ULONG));
        
dpix buf;

        for(
0widthx++)
        {
          
ULONG srcpixdstpixargb;

          
srcpix = *spix++;
          
dstpix = *dpix;

          
= (srcpix >> 24) & 0xff;
          
= (srcpix >> 16) & 0xff;
          
= (srcpix >> 8) & 0xff;
          
= (srcpix >> 0) & 0xff;

          
globalalpha;

          if(
0)
          {
            
ULONG dest_rdest_gdest_b;

            
dest_r = (dstpix >> 16) & 0xff;
            
dest_g = (dstpix >> 8) & 0xff;
            
dest_b = (dstpix >> 0) & 0xff;

            
dest_r += do_alpha(adest_r);
            
dest_g += do_alpha(adest_g);
            
dest_b += do_alpha(adest_b);

            
dstpix 0xff000000 dest_r << 16 dest_g << dest_b;
          }

          *
dpix++ = dstpix;
          
pixels++;
        }

        
//WritePixelArray(buf, 0, 0, width * 4, rp, destx, desty + y, width, 1, RECTFMT_ARGB);
        
WritePixelArray((uint8 *)buf,0,0,width *4PIXF_A8R8G8B8,rp,destxdesty ywidth1);
      }

      
FreeVec(buf);
    }
  }

  return 
pixels;
}


So while ok, there is issue with AllocVecShared() line. I can't build it as it without -fpermissive. It seems need some APTR cast or something again in "if((buf = AllocVecShared(width * 4, MEMF_ANY)) != NULL)" part.

I currently make it like:

if((buf = (ULONG *)AllocVecShared(width * 4, MEMF_ANY)) != NULL)

(adding ULONG *), but not sure again if it correct way. Through if buf are ULONG*, then why not.

Will check now if it will works at all as Cybergarphics's one.

   Report Go to top

Re: Odyssey's MediaPlayer thread
Home away from home
Joined:
2006/11/20 16:26
From Norway
Posts: 2793
@kas1e

Write new _WPPA function and use the old one as fallback.

   Report Go to top

Re: Odyssey's MediaPlayer thread
Just can't stay away
Joined:
2007/7/14 21:30
From Lothric
Posts: 1069
@kas1e

(ULONG *) is the correct cast here in my opinion. APTR is defined as void* so casting void* to APTR wouldn't be useful.

   Report Go to top

Re: Odyssey's MediaPlayer thread
Home away from home
Joined:
2007/9/11 12:31
From Russia
Posts: 6325
@Capehill
Ok, added, compiled, tested: it works!

So probably now we can just add that and ifdefed cgx be only for morphos (but removed fully interface and library opening in main.cpp, as it already os4 only). As there not many parts in general, ifdefs should be fine for now.

For owbbrowserclass we as next step rename/clean it, etc (just while it ifdefs, it easer for me later to put the same to 1.25). Plus, bunch of stuff you comments in owbbrowserclass still need it for us for compositing video playing (to be able to handle videos as expected, with resizing, be in tabs, etc).

So we can now currently remove cgx via ifdefs, and then as next step create a copy of owbbrowserclass , remove cgx from totally together with ifdefs, and start adding compositing code in what we have left.

   Report Go to top

Re: Odyssey's MediaPlayer thread
Just can't stay away
Joined:
2007/7/14 21:30
From Lothric
Posts: 1069
@kas1e

Any MorphOS users going to use this code?

   Report Go to top

Re: Odyssey's MediaPlayer thread
Home away from home
Joined:
2007/9/11 12:31
From Russia
Posts: 6325
@Capehill
Surely no anymore. They have their own branch sources of which they not share, and they works on new browser anyway.

But there is 1.25 version for AROS (with 2 years more recent webkit core, and which is the version we need to port first as it structured well, and applying new core on top of it will be easer). And that version has most of the same gui code, and when i port it few weeks ago it was easy for me to just copy "amigaos4 ifdefs" from current version.

But from another side, we do have github history, where i can see everything.. So probably you right, let's remove CGX all together and forget about.

   Report Go to top

Re: Odyssey's MediaPlayer thread
Just popping in
Joined:
2007/1/10 21:56
From Stockholm Sweden
Posts: 94
@ktadd

Donated to kas1e a few weeks ago for his amazing christmas presents.

Donated to Capehill just now.

@Ami603

You want money? Give us a link. ;)

   Report Go to top

Re: Odyssey's MediaPlayer thread
Home away from home
Joined:
2007/9/11 12:31
From Russia
Posts: 6325
@khayoz
Ami603's paypal acc are ami603@terra.es

@Capehill
So made a commit to fully delete CGX usage (c) Capehill. Also added custom WritePixelArrayAlpha() implementation we talks about from Thore. So everything in, and there even wasn't need to change WritePixelArrayAlpha, it works just like original.

So.. Next thing is probabaly start to integrate compositing parts.. Can you review if you can add things Ami603 do as well from there: http://kas1e.mikendezign.com/a/owbbrowserclass3.cpp

With that one we can resize window, all centered, plays fine (because it also use same code as it was for morphos in terms of gui handling). It have some bugs through like :

1). When we switch to another tab, video still plays
2). When iconify back from fullscreen, it's iconified to window mode.
3). Need to add checks on the possibility of compositing, and depend on that use it or not use (to avoid crashes on machines which didn't have that).


We already can strip off CGX part for fullscreen in owbbrowserclass as all things about cgx removed, and we agree that noone will use that code anyway on anything but os4.

   Report Go to top

Re: Odyssey's MediaPlayer thread
Just popping in
Joined:
2006/12/27 21:09
Posts: 86
@khayoz,@ktadd, @others

Thanks for the donations, truly appreciated.


   Report Go to top

Re: Odyssey's MediaPlayer thread
Just can't stay away
Joined:
2007/7/14 21:30
From Lothric
Posts: 1069
@kas1e

1) Is it considered a bug? What is behaviour on MorphOS? At least Firefox continues to play video on non-active tabs.

2) Possibly intentional (didn't debug): https://github.com/kas1e/Odyssey/blob/ ... S/owbwindowclass.cpp#L843

3) Yes. Perhaps check graphics.library V54 first and if positive, try a test render. If it fails, the try to fallback to normal mode. Or should it try P96 PIP mode as in Hans' examples?

   Report Go to top

Re: Odyssey's MediaPlayer thread
Home away from home
Joined:
2007/9/11 12:31
From Russia
Posts: 6325
@Capehill
Quote:

1) Is it considered a bug? What is behaviour on MorphOS? At least Firefox continues to play video on non-active tabs.


What i mean there, is that if i start to play video in fullscreen in one tab, and then swith to another tab, then video continu to be played not in background, but in new tab overwriting new tab context.

Quote:

2) Possibly intentional (didn't debug): https://github.com/kas1e/Odyssey/blob/ ... S/owbwindowclass.cpp#L843


That one and first one will recheck on MorphOS how behave.

Quote:

3) Yes. Perhaps check graphics.library V54 first and if positive, try a test render. If it fails, the try to fallback to normal mode. Or should it try P96 PIP mode as in Hans' examples?


PIP mode will not works with odyssey, as PIP in p96 can works only in fullscreen as i aware, and so, it will mean we need to write tons of additional code to handle keys/stuff/etc to be able to interract with odyssey. Hard work and i do not know who will do so ever.

What we need now, it just some fast check on ability to use compositing. If we can, then "int compositing=1", if we can't , then "int compositing=0" and everything go as before.

   Report Go to top

Re: Odyssey's MediaPlayer thread
Home away from home
Joined:
2007/9/11 12:31
From Russia
Posts: 6325
@Capehill
Checked morphos version : yeah, then also switch to window mode when de-iconify, even if video was in fullscreen. But in terms of tabs, all works as expected on mos : you play fullscreen video in one tab, swithc to another one and use it as you wish, video didn't overwrite content of new tab. Trying to fix with Ami603 now

ps. making another commit : getting rid of -lauto, and open/close everything manually. Hope didn't broken anything, at least in "timer" part.

   Report Go to top

Re: Odyssey's MediaPlayer thread
Home away from home
Joined:
2007/9/11 12:31
From Russia
Posts: 6325
@All
So there is no easy way to check if compositing-video available ? I mean something like return from compositingtag function or so ? Should we in any case do some "test" with all those DoHookClipRects() to some invisibly window before or something ?


   Report Go to top

Re: Odyssey's MediaPlayer thread
Home away from home
Joined:
2007/1/26 21:48
From New Zealand
Posts: 2310
@kas1e

Quote:
So there is no easy way to check if compositing-video available ? I mean something like return from compositingtag function or so ? Should we in any case do some "test" with all those DoHookClipRects() to some invisibly window before or something ?


Do a CompositeTags() call with the "hardware-only" tag set. It'll fail with an error code if the driver doesn't support it. IIRC, at least one of the CompositeYUV examples demonstrates how to do this.

Hans

   Report Go to top

Re: Odyssey's MediaPlayer thread
Home away from home
Joined:
2007/9/11 12:31
From Russia
Posts: 6325
@Hans
Will something simple like this works ?

Quote:

retcode = IGraphics->CompositeTags(COMPOSITE_Src_Over_Dest, NULL, NULL,
COMPTAG_Flags, COMPFLAG_HardwareOnly,
TAG_DONE);


Or it needit src/dest in any case even for querying hardware support ?

   Report Go to top

Re: Odyssey's MediaPlayer thread
Just can't stay away
Joined:
2007/7/14 21:30
From Lothric
Posts: 1069
@kas1e

Quote:
Can you review if you can add things Ami603 do as well from there: http://kas1e.mikendezign.com/a/owbbrowserclass3.cpp


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 *".

   Report Go to top


« 1 2 3 4 (5) 6 7 8 ... 15 »



[Advanced Search]



Powered by XOOPS 2.0 © 2001-2016 The XOOPS Project