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)
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:
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
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.
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.
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.
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.
@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.
@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.
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.
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?
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.
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.
@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.
@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 ?
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.
News feed
OS4 Feedback forum
OS4Depot Feedback forum
Amigabounty forum
OpenAmiga forum
AmiCygnix forum
ABC shell forum
AmiKit forum
Cinnamon Writer forum
CodeBench forum
Digital Universe forum
Dopus 5 forum
E-UAE forum
Gnash forum
Ibrowse forum
JAmiga forum
Odyssey forum
OWB forum
Qt forum
SmartFileSystem forum
Timberwolf forum
TouchDevice forum
TuneNet forum
Unsatisfactory Software forum
Donate
