Home  
Login
Username:

Password:

Remember me



Lost Password?

Register now!
Sections
Who's Online
52 user(s) are online (34 user(s) are browsing Forums)

Members: 1
Guests: 51

tolkien, more...
Support us!
Recent OS4 Files
OS4Depot.net



« 1 2 3 4 (5)


Re: We so need an updated browser!
Just popping in
Joined:
2007/7/30 21:55
From Sweden
Posts: 180
Quote:

No... Or... yes? Can't remember which ones I used, but I should probably have used those you point at. Thinking about it, I might have actually used a diff from that place.
I'm having a hard time understanding which exact revision "our" Odyssey is using, and which ones the leopard-webkit uses. I looked at it several times but always end up confused since I always seems to find huge discrepancies between files.

Quote:
Did you manage to compile a working binary?

Nope. Never got that far.

_________________
Maintainer and developer for Jamiga2 - Java for Amiga
   Report Go to top

Re: We so need an updated browser!
Just can't stay away
Joined:
2007/1/26 21:48
From New Zealand
Posts: 1800
@kas1e

Angle provides GLES2 on desktop machines. Technically we don't need it because we have a GLES2 implementation, but it also has a GLES2 backend, so it won't hurt.

I hope someone takes a look at this, because I consider this more important than JIT (which is also pretty important).

Hans

_________________
http://hdrlab.org.nz/ - Amiga OS 4 projects, programming articles and more.
https://keasigmadelta.com/ - more of my work
   Report Go to top

Re: We so need an updated browser!
Home away from home
Joined:
2007/9/11 11:31
From Russia
Posts: 4154
@Hans
Strange that once i do ENABLE_WEBGL , sources even didn't try to search for any GL related includes.

As i understand webgl in webkit based on Angle, so we need it anyway for easy build.

Checked source of current webkit, and found that:
https://trac.webkit.org/browser/webkit ... k/Source/ThirdParty/ANGLE

Dunno how it all mean to be build at moment, should i separately build it and link with, or somehow add necesary code , dunno at moment.

I also found that, in 2012 they change Change ENABLE_3D_CANVAS to ENABLE_WEBGL , so maybe i should try ENABLE_3D_CANVAS as well, maybe it still keeps in our sources..

_________________
Join us to improve dopus5!
zerohero's mirror of os4/os3 crosscompiler suites
   Report Go to top

Re: We so need an updated browser!
Home away from home
Joined:
2007/9/11 11:31
From Russia
Posts: 4154
@Hans
Checked some old aros sources (port of 1.16 version), where WebGL was enabled, And there in AROS directory deadwood have directory Angle. There is content if you in interest to check: http://kas1e.mikendezign.com/aos4/odyssey/temp/ANGLE_aros.ZIP

Which is seems stripped down version of https://trac.webkit.org/browser/webkit ... /Source/ThirdParty/ANGLE/ from webkit.

At least from changelog in both places , i can see that this one from old aros build, have the same parts from current changelog, just 5 years old :) I.e. last entry in that old AROS build are from 2012-01-07 from Chris Marrin, which i found in https://trac.webkit.org/export/216970/ ... hirdParty/ANGLE/ChangeLog.

So, at least we know now its all take from ebkit/trunk/Source/ThirdParty/ANGLE/

And that it need to be build separately as libangle.a , and linked with odyssey binary at end.

Now, need to understand what need to change and where to make use of it. As i see in that ANGLE directory from old aros build, there is few AROS ifdefs as well, as well as in the Odyssey source code ..

As well as why when i enable WEBGL, nothing changes in the Cmakefiles at all ..

_________________
Join us to improve dopus5!
zerohero's mirror of os4/os3 crosscompiler suites
   Report Go to top

Re: We so need an updated browser!
Home away from home
Joined:
2007/5/19 13:23
From England
Posts: 3375
@Hans Quote:
I consider this more important than JIT (which is also pretty important).

Why is WebGL even *slightly* important? It's not like we want/need to want to run games inside our Amiga browser. And I thought I remembered reading on a non-Amiga site that WebGL is basically dead (unused anywhere), although I might be mistaken.

P.S. I got the impression (I could be wrong) that for JavaScript, when WebKit is compiled, it uses *either* interpreted *or* JIT (and both have very different endian problems). Therefore if endian problems can be fixed for JIT (and it sounds like "bigfoot" got very close), then we don't need to fix interpreted JavaScript's 'unsolvable' endian problems...

_________________
Author of the PortablE programming language.
I love using Amiga OS4.1
It is pitch black. You are likely to be eaten by a grue...
   Report Go to top

Re: We so need an updated browser!
Home away from home
Joined:
2007/9/11 11:31
From Russia
Posts: 4154
@Hans
After taked a look at CMakefiles, seems that in morphos sources its all just or deleted, or even wasn't added at all. For example:

cmake/SetCMakeVars.cmake didn't containt anything about WEBGL (there is library to which link).

and source/webcore/platform/CMakeList.txt , didn't contain as well anything about WEBGL, while for aros it contain list of files which need to build to have WEBGL stuff:

Quote:

if(ENABLE_WEBGL)
list(APPEND WEBCORE_SRC
platform/graphics/opengl/Extensions3DOpenGL.cpp
platform/graphics/opengl/GraphicsContext3DOpenGL.cpp
platform/graphics/opengl/GraphicsContext3DOpenGLCommon.cpp
platform/graphics/gpu/DrawingBuffer.cpp
platform/graphics/cairo/OpenGLShims.cpp
platform/graphics/aros/GraphicsContext3DAROS.cpp
platform/graphics/aros/GraphicsContext3DPrivate.cpp
platform/graphics/aros/DrawingBufferAROS.cpp
platform/graphics/ANGLEWebKitBridge.cpp
)
endif(ENABLE_WEBGL)


I do check sources i have, for directories from where old aros build grab files for webgl, and i have all of them, just inside few other files as well. For example, in webcore/platform/graphics/opengl/ we have:

Quote:

Extensions3DOpenGL.cpp
Extensions3DOpenGL.h
Extensions3DOpenGLCommon.cpp
Extensions3DOpenGLCommon.h
Extensions3DOpenGLES.cpp
Extensions3DOpenGLES.h
GLDefs.h
GLPlatformContext.cpp
GLPlatformContext.h
GLPlatformSurface.cpp
GLPlatformSurface.h
GraphicsContext3DOpenGL.cpp
GraphicsContext3DOpenGLCommon.cpp
GraphicsContext3DOpenGLES.cpp


See there OpenGLES one, so maybe that one we should use instead of GraphicsContext3DOpenGL.cpp and GraphicsContext3DOpenGLCommon.cpp.


But at first i probably should just download latest ANGLE from webkit, and trying to build libangle.a , just to see, if with our currentl OpenGLES2 it can builds. Then once that done, we can try to include it to odyssey the way on AROS was done.

_________________
Join us to improve dopus5!
zerohero's mirror of os4/os3 crosscompiler suites
   Report Go to top

Re: We so need an updated browser!
Just can't stay away
Joined:
2007/1/26 21:48
From New Zealand
Posts: 1800
@ChrisH
Quote:
Why is WebGL even *slightly* important? It's not like we want/need to want to run games inside our Amiga browser.

The trend appears to be toward more WebGL based games, apps and content online, so I wouldn't be so quick to dismiss it.

I consider it more important than JIT because it adds more functionality whereas having JIT doesn't.

Quote:
And I thought I remembered reading on a non-Amiga site that WebGL is basically dead (unused anywhere), although I might be mistaken.

That's total BS.

Hans

_________________
http://hdrlab.org.nz/ - Amiga OS 4 projects, programming articles and more.
https://keasigmadelta.com/ - more of my work
   Report Go to top

Re: We so need an updated browser!
Quite a regular
Joined:
2013/10/17 15:21
From Hungary
Posts: 531
@ChrisH
Fixing the endianness issues in the JSC JIT is orders of magnitudes more difficult than fixing the interpreter, if bigfoot's word is anything to go by.
Either way, doing WebGL with interpreted JS would be a slideshow.

_________________
I see the jimmies have been rustled.
   Report Go to top

Re: We so need an updated browser!
Just can't stay away
Joined:
2007/1/26 21:48
From New Zealand
Posts: 1800
@BSZili

Quote:
Either way, doing WebGL with interpreted JS would be a slideshow.

That depends entirely on what's being run. Well designed code that doesn't have to do too much on the CPU side should run okay.

@kas1e

Almost forgot about this...
Quote:
Our version have DENABLE_NPAPI:BOOL=ON (as morphos one), and if i remember right we rewrite some part related to plugins, but only one plugin was exits : flash one, which sources we don't have and can't test if all works in terms of plugins or not.

So, the plugin API is basically untested on AmigaOS? We don't have even a skeleton/example plugin with source-code? How would anyone go about writing a plugin then?

Hans

_________________
http://hdrlab.org.nz/ - Amiga OS 4 projects, programming articles and more.
https://keasigmadelta.com/ - more of my work
   Report Go to top

Re: We so need an updated browser!
Home away from home
Joined:
2007/9/11 11:31
From Russia
Posts: 4154
@Hans
Quote:

So, the plugin API is basically untested on AmigaOS? We don't have even a skeleton/example plugin with source-code? How would anyone go about writing a plugin then?


Not only not-tested, but as i found for now even not ported, just dummied..

Its just for now:

#ifdef __amigaos4__

#define NP_Initialize(__p0) (NPERR_GENERIC_ERROR)
#define NP_ShutDown(__p0) (NPERR_GENERIC_ERROR)
#define NP_GetEntryPoints(__p0) (NPERR_GENERIC_ERROR)
#define NP_GetMIMEDescription() (NPERR_GENERIC_ERROR)

#else

// MORPHOS's originals:

#include <ppcinline/macros.h>

#define PLUGIN_BASE_NAME this->m_module

#define NP_Initialize(__p0) 
    
LP1(30short NP_Initialize
        
void *, __p0a0
        , 
PLUGIN_BASE_NAME000000)

#define NP_ShutDown(__p0) 
    
LP0(36short NP_ShutDown
        , 
PLUGIN_BASE_NAME000000)

#define NP_GetEntryPoints(__p0) 
    
LP1(42short NP_GetEntryPoints
        
void *, __p0a0
        , 
PLUGIN_BASE_NAME000000)

#define NP_GetMIMEDescription() 
    
LP0(48char *, NP_GetMIMEDescription
        , 
PLUGIN_BASE_NAME000000)
#endif


There is just those 3 files from the WebCore/Plugins/ directory, so you can see how it looks like and what it expect (from os4 port already, i.e. how it now):

http://kas1e.mikendezign.com/aos4/odyssey/temp/plugins/

Those dummy defines (and morphos's originals) are in PluginPackageMorphOS.cpp.

But, plugins support from Odyssey side is relatively easy, it's just library calls. The hard part is in the plugin itself :) It is npapi plugins, for which Fab used a ibrary interface, not the usual .so stuff. In other words, plugin = library. On morphos that single plugin they have (sfwdec), are classic morphos library as well.

In 2011 , when i first time start to worry about port, and Fab was pretty helpfull, i ask him about plugin-skeleton-example-code, and he say "maybe this weekend, but it needs quite some work to clean it up". That was 6 years ago probably :)

But, i still have some more info i note from him back in past: writing a plugin isn't really hard, except it needs relative base address per opener, to store global data. then the problem is rather about the plugins you want to have, anyway. And we can't make just single tiny example, with just some window with "hello-word", as it's a bit more complicated than that, and there's no "window". it's mimetype based.

That all what i can find and sort in my logs with Fab about plugins.

In other words, and if we take in account it is NPAPI plugin, we need:

1. Rewrite those 4 macroses (probably, should be easy). If anyone can do so, i can easyly rebuild Odyssey with it.

2. Then hard part: plugin itself. Probably we can create first dummy library, with those 4 additional functions with names as defined in macroses in odysseys code (if i uderstand it right), and then, test it by some very easy cross-compile npapi based code taken from elsewhere.

Its all can be done, if anyone willing to help me with.


Edited by kas1e on 2017/5/18 13:32:32
Edited by kas1e on 2017/5/18 13:36:37
Edited by kas1e on 2017/5/18 13:53:46
Edited by kas1e on 2017/5/18 13:54:21
Edited by kas1e on 2017/5/18 14:12:53
_________________
Join us to improve dopus5!
zerohero's mirror of os4/os3 crosscompiler suites
   Report Go to top

Re: We so need an updated browser!
Home away from home
Joined:
2007/9/11 11:31
From Russia
Posts: 4154
@Hans
There is also plugin-helpers in amiga native code, that one Deniil rewrite already:

/* Plugin helpers */

#ifdef __amigaos4__

static __inline IPTR _CALLFUNC1(IPTR (*func)(IPTR), IPTR arg1) { return func(arg1); }
#define CALLFUNC1(f,a1) _CALLFUNC1((IPTR (*)(IPTR))(f),(IPTR)(a1))
static __inline IPTR _CALLFUNC2(IPTR (*func)(IPTR,IPTR), IPTR arg1IPTR arg2) { return func(arg1,arg2); }
#define CALLFUNC2(f,a1,a2) _CALLFUNC2((IPTR (*)(IPTR,IPTR))(f),(IPTR)(a1),(IPTR)(a2))

#else


// MORPHOS original part:

#include <emul/emulinterface.h>
#include <emul/emulregs.h>


static __inline IPTR _CFCALL(void (*func)(void))
{
    const 
UWORD *funcptr = (const UWORD *) func;
    
IPTR res;
    if (
funcptr[0] >= TRAP_AREA_STARTREG_A7 -= sizeof(IPTR);
    
res MyEmulHandle->EmulCallDirect68k((void *) func);
    if (
funcptr[0] >= TRAP_AREA_STARTREG_A7 += sizeof(IPTR);
    return 
res;
}

static 
__inline IPTR _CALLFUNC1(void (*func)(void), IPTR arg1)
{
    
IPTR res, *sptr;
    
REG_A7 -= sizeof(IPTR);
    
sptr = (IPTR *) REG_A7;
    
sptr[0] = arg1;
    
res _CFCALL(func);
    
REG_A7 += sizeof(IPTR);
    return 
res;
}
#define CALLFUNC1(f,a1) _CALLFUNC1((void (*)(void))(f),(IPTR)(a1))

static __inline IPTR _CALLFUNC2(void (*func)(void), IPTR arg1IPTR arg2)
{
    
IPTR res, *sptr;
    
REG_A7 -= sizeof(IPTR);
    
sptr = (IPTR *) REG_A7;
    
sptr[0] = arg1;
    
sptr[1] = arg2;
    
res _CFCALL(func);
    
REG_A7 += sizeof(IPTR);
    return 
res;
}
#define CALLFUNC2(f,a1,a2) _CALLFUNC2((void (*)(void))(f),(IPTR)(a1),(IPTR)(a2))

#endif


But as i see that part almost not used, at least CALLFUNC1 not used for sure, and CALLFUNC2 used one time, in the handleevent(), so we probably can not worry about that one (taken in account that it rewrited right already).

Fab says back in past that this requires relative base libraries, too, but dunno, probably can just skip it now if no gurus there :)

We can concetrate just on those 4 macroses probably, and it will just works from odyssey's side.


Edited by kas1e on 2017/5/18 13:48:23
Edited by kas1e on 2017/5/18 13:52:56
_________________
Join us to improve dopus5!
zerohero's mirror of os4/os3 crosscompiler suites
   Report Go to top

Re: We so need an updated browser!
Home away from home
Joined:
2006/11/20 16:26
From Norway
Posts: 2612
@kas1e

Way even care about NPAPI, browsers this days comes whit NPAPI disabled, because its security risk, HTML5 killed FlashPlayer, so what is left is annoying JavaVM plugin.

https://productforums.google.com/forum/#!topic/chrome/h_cOUMvDzGQ

_________________
(NutsAboutAmiga)

Basilisk II for AmigaOS4
AmigaInputAnywhere
Excalibur
and other tools and apps.
   Report Go to top

Re: We so need an updated browser!
Just can't stay away
Joined:
2007/1/26 21:48
From New Zealand
Posts: 1800
@LiveForIt

Why care? Because we have NPAPI, whereas we don't have any of the more secure plugin APIs that replaced it. It's still useful to have some way of adding plugins/extensions.

Hans

_________________
http://hdrlab.org.nz/ - Amiga OS 4 projects, programming articles and more.
https://keasigmadelta.com/ - more of my work
   Report Go to top

Re: We so need an updated browser!
Quite a regular
Joined:
2013/10/5 14:07
From Italy
Posts: 586
just for info im writing from last 603 version of leopard webkit all is running ok . i sow sources are available on sourceforce

_________________
X5000 beta tester
   Report Go to top


« 1 2 3 4 (5)



[Advanced Search]


Powered by XOOPS 2.0 © 2001-2016 The XOOPS Project