We so need an updated browser!

	Bottom Previous Topic Next Topic
Register To Post

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

jaokim

Re: We so need an updated browser!

Posted on: 2017/5/16 17:15 #81

Just popping in

Quote:

Did you use patches from https://sourceforge.net/projects/leopard-webkit/files/602/Sources/ ?

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

Hans

Re: We so need an updated browser!

Posted on: 2017/5/17 2:11 #82

Home away from home

@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

Join Kea Campus' Amiga Corner and support Amiga content creation
https://keasigmadelta.com/ - see more of my work

kas1e

Re: We so need an updated browser!

Posted on: 2017/5/17 8:07 #83

Home away from home

@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!
AmigaOS4 on youtube

kas1e

Re: We so need an updated browser!

Posted on: 2017/5/17 8:56 #84

Home away from home

@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!
AmigaOS4 on youtube

ChrisH

Re: We so need an updated browser!

Posted on: 2017/5/17 8:59 #85

Home away from home

@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.

kas1e

Re: We so need an updated browser!

Posted on: 2017/5/17 9:23 #86

Home away from home

@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!
AmigaOS4 on youtube

Hans

Re: We so need an updated browser!

Posted on: 2017/5/17 11:35 #87

Home away from home

@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

Join Kea Campus' Amiga Corner and support Amiga content creation
https://keasigmadelta.com/ - see more of my work

BSzili

Re: We so need an updated browser!

Posted on: 2017/5/17 12:37 #88

Quite a regular

@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.

This is just like television, only you can see much further.

Hans

Re: We so need an updated browser!

Posted on: 2017/5/18 11:11 #89

Home away from home

@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

Join Kea Campus' Amiga Corner and support Amiga content creation
https://keasigmadelta.com/ - see more of my work

kas1e

Re: We so need an updated browser!

Posted on: 2017/5/18 14:07 #90

Home away from home

@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(30, short , NP_Initialize, \

        void *, __p0, a0, \

        , PLUGIN_BASE_NAME, 0, 0, 0, 0, 0, 0)



#define NP_ShutDown(__p0) \

    LP0(36, short , NP_ShutDown, \

        , PLUGIN_BASE_NAME, 0, 0, 0, 0, 0, 0)



#define NP_GetEntryPoints(__p0) \

    LP1(42, short , NP_GetEntryPoints, \

        void *, __p0, a0, \

        , PLUGIN_BASE_NAME, 0, 0, 0, 0, 0, 0)



#define NP_GetMIMEDescription() \

    LP0(48, char *, NP_GetMIMEDescription, \

        , PLUGIN_BASE_NAME, 0, 0, 0, 0, 0, 0)

#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 14:32:32
Edited by kas1e on 2017/5/18 14:36:37
Edited by kas1e on 2017/5/18 14:53:46
Edited by kas1e on 2017/5/18 14:54:21
Edited by kas1e on 2017/5/18 15:12:53

Join us to improve dopus5!
AmigaOS4 on youtube

kas1e

Re: We so need an updated browser!

Posted on: 2017/5/18 14:31 #91

Home away from home

@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 arg1, IPTR 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_START) REG_A7 -= sizeof(IPTR);

    res = MyEmulHandle->EmulCallDirect68k((void *) func);

    if (funcptr[0] >= TRAP_AREA_START) REG_A7 += sizeof(IPTR);

    return res;

}



static __inline IPTR _CALLFUNC1(void (*func)(void), IPTR arg1)

{

    IPTR res, *sptr;

    REG_A7 -= 1 * sizeof(IPTR);

    sptr = (IPTR *) REG_A7;

    sptr[0] = arg1;

    res = _CFCALL(func);

    REG_A7 += 1 * sizeof(IPTR);

    return res;

}

#define CALLFUNC1(f,a1) _CALLFUNC1((void (*)(void))(f),(IPTR)(a1))



static __inline IPTR _CALLFUNC2(void (*func)(void), IPTR arg1, IPTR arg2)

{

    IPTR res, *sptr;

    REG_A7 -= 2 * sizeof(IPTR);

    sptr = (IPTR *) REG_A7;

    sptr[0] = arg1;

    sptr[1] = arg2;

    res = _CFCALL(func);

    REG_A7 += 2 * 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 14:48:23
Edited by kas1e on 2017/5/18 14:52:56

Join us to improve dopus5!
AmigaOS4 on youtube

LiveForIt

Re: We so need an updated browser!

Posted on: 2017/5/18 18:47 #92

Home away from home

@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.

Hans

Re: We so need an updated browser!

Posted on: 2017/5/19 2:22 #93

Home away from home

@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

Join Kea Campus' Amiga Corner and support Amiga content creation
https://keasigmadelta.com/ - see more of my work

tlosm

Re: We so need an updated browser!

Posted on: 2017/5/21 12:09 #94

Quite a regular

just for info im writing from last 603 version of leopard webkit all is running ok . i sow sources are available on sourceforce

~~X5000/40 16GB~~
RasperryPi 1-2-3-4-(5)
A500 Mini.

Hans

Re: We so need an updated browser!

Posted on: 2017/5/25 4:14 #95

Home away from home

@kas1e
Quote:

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

I see. Well, without a skeleton plugin that correctly implements the API, it'll be hard to get it right. Ideally we'd have the swfdec plugin... if Fab is prepared to share it.

That said, I'm more interested in WebGL capability than getting the plugin facility working. Getting an updated Webkit (with endianness issues fixed) would be more useful too. I thought that plugins might provide a means of adding functionality in interim, if it was already working.

Hans

Join Kea Campus' Amiga Corner and support Amiga content creation
https://keasigmadelta.com/ - see more of my work

LiveForIt

Re: We so need an updated browser!

Posted on: 2017/5/25 11:16 #96

Home away from home

@Hans

I do not know if this popular 3D images where change camera angel is using WebGL or not, but I guess it required, it be nice to see this images.

Faster Javascript, be huge improvement.
This 2 things are maybe two most important. Then there is general stability, we don't have 100% safe memory protection, we can't terminate programs when they fail, this means that stability of web browser is 100% more important the on Windows or Linux, and we don't have undimmed ram, as we only have 32bit OS, memory leaks is also real problem.

Maybe the next stage in OS development should be to create a sandbox for unsafe programs, simulator to Linux User Mode Kernel (UML), so when program crash we terminate the sandbox, or so we stop programs when they trying to ate up all ram, or terminate programs.

Can be next logical step to run 32bit programs in a 64bit OS as well.

Edited by LiveForIt on 2017/5/25 11:37:08

(NutsAboutAmiga)

Basilisk II for AmigaOS4
AmigaInputAnywhere
Excalibur
and other tools and apps.

Fairdinkem

Re: We so need an updated browser!

Posted on: 2017/6/17 4:14 #97

Just popping in

I wonder why the A-Eon Developer team or Hyperion see no value in making a fully functional, up to date modern browser a priority? I mean seriously Timberwolf, what a missed opportunity that was. I know there are detractors in the community about this but the fact is a Firefox port gives opportunity for plugins like no other browsers and the browser has active support in the linux arena. I accept the fact its a large undertaking requiring someone to maintain the port, but if you are going to be a real company releasing an operating system and selling new hardware in 2017 you need a Web Browser that is in parity with whats on offer and available on other platforms.

328gts

Re: We so need an updated browser!

Posted on: 2017/6/17 9:08 #98

Home away from home

@Fairdinkem

+ infinity & has been said infinity to the power of infinity times sadly. Timberwolf was working great at one time with my favourite Firefox plugins working nicely but once FE came along that all changed. The bros abandoned it ...

_______________________________
c64-dual sids, A1000, A1200-060@50, A4000-CSMKIII
Catweasel MK4+= Amazing
! My Master Miggies-Amiga1000 & AmigaONE X1000 !
mancave-ramblings

Raziel

Re: We so need an updated browser!

Posted on: 2017/6/17 9:59 #99

Home away from home

@328gts

I really don't hope LibreOffice goes the same road...making it work with FE and then abandoning it *if*/when OS4.1/2/2007/2008/whatever comes along.

@Fairdinkem

I'm so with you...a browser, supported and further developed, with latest technology, plugin support, HTML5 CSS3, you name it...would sell order of magnitudes to the stuff they sell now (and would be orders of magnitudes more usefull aswell).

Heck i'd even pay for a beta that only has limited functionality and for every updates that would introduce more features, but obviously they don't want my money...

--

game box/art scans
scummvm infrequent builds

kas1e

Re: We so need an updated browser!

Posted on: 2017/6/18 18:16 #100

Home away from home

@Fairdinkem
Quote:

I wonder why the A-Eon Developer team or Hyperion see no value in making a fully functional, up to date modern browser a priority?

Because of factor everyone know and it is : not big enough user base to spend real resources and real money in , and as result no ability to make any real income.

Browser its kind of heavy application, which need someone working on it full time (and that mean at least 2 thousand euros per month), or even few ppls. In other words that can cost easyly 5-6 thousands _PER MONTH_ to make it "all right", and hire professionals to be on stage with everyday changed internet.

But ok, let's say it will be 1 man, and he will work for 1.5k, now, it will be about 20k for 1 year, if aoen or hyperion can find person who skilled enough, and can drop all his project to work just on one, for 1.5k per month.

Now, how much anyone who will spend 20k (that minimum, but it can be 30,40,50k for year), his time, etc, will got when he will sale that browser ?:) Answer is: nothing. There will be about 100 sales maximum, if it will be around 100$. If it will cost more, then there will be about 50-70 sales in whole :)

So, kind of strange to spend 20k (or more) , loose time, etc, etc, to got in end 10k at maximum.

And i even do not point on that fact, that person who can be hired for such job, should know very well internals of amigaos, be sane, share beta-version every week, listen to all bugreports, etc, etc.

And all that mean of course usage of webkit probably, mantining ppc version of all jits in webkit and so on. Be in sync with gazilion of changes webkit devs do every day.

In other words, i dind't see how with current user base, you can expect that anyone will worry about something like new browsers , even based on something opensourced like webkit.

Join us to improve dopus5!
AmigaOS4 on youtube

Register To Post	« 1 2 3 4 (5) 6 7 8 »
	Top Previous Topic Next Topic

Currently Active Users Viewing This Thread: 1 ( 0 members and 1 Anonymous Users )