WebKit based browser initiative

@kas1e

Quote:I don't know how the current AmigaOS GCC versions work. There were AmigaOS GCC versions using a PIPE: to pass the output from cc1 to gas and running both at the same time (would only make it much faster with multicore support, which AFAIK still isn't supported by AmigaOS 4.x. With a single CPU core it's only a little bit faster because gas can run while cc1 is waiting for disk transfers, but running both at the same time requires more RAM as well), other versions of GCC put the output of cc1 to T:, which is usually on RAM Disk:, and only started gas with it as input file after cc1 finished.

With the 2nd method and a RAM Disk using ExtMem you automatically take advantage of it.

Not necessarily relevant to the current thread. But I *did* already do a complete build of chromium for Qt6 with a cross compiler, and it didn't link correctly, and it was a mean bitch to work with. I do believe, it is within the realm of the theoretically possible getting it to work, but it is not very much fun doing the work, and I might decline doing anything further with it, unless there is some really serious motivation involved.

I think this thread is interesting with a more sensible goal orientation. I did do the Qt4 webkit module on a similar code base, so maybe I would have some knowledge to chip in. Hoping to see it developing further.

@alfkil

Quote:Sounds good, I'd try to go that way. "Just" porting WebKit without a browser is quite useless...

@joerg

Nothing today can replace crosscompiling : not because of speed of compilation, but also because of all the latest tools like cmakes, bisons, awks and co not avail on OS4 (only some veeeery old versions which no one use anymore in any project). They all avail on crosscompiler and works well and bug free, and todays WebKit use it as well. We can't even updating binutils to the latest ones, so of course all the tools are long ago outdated (+ specific to port bugs). And we end up only with cross-compiler if we want to make a real work and not just tinker with code a little bit.

As for :

Quote:

IMHO today _exactly_ porting of webkit make a sense (because of endian issues and all that), and making it as shared class, so any programmer can write any kind of crap-gui on top of it, from any language he wish to use, and with any gui toolkit he want to use.

Quote:

Ram disk may use ExtMem (i do not remember if it is), but it not as fancy as it may sounds : pure filling up of the RAM still die after 1.8 GB of filled ram and amigaos died too after. At leat that how it is now with all beta components used. And i do not know if even doing pure "copy 4gb file from a shell to ram disk" will work as well. Probabaly will the same die on 1.8gb.

In other words, it all may sounds good and fine, but in end everyone who want to consider making something with todays bloated webkit turned up to use cross-compiler as only real solution.

Even with 10 years old WebKit (which we use in latest version of Odyssey), it was already about 5 hours to compile whole webkit on fast and modern PC with cross-compiler, and the only times when we use native compiling was when Daniel from onyxsoft helping me with rewritting morphos's parts to amigaos4's analogs. He have only x1000 at this time, and then i created for him manualy makefiles to build only libwebkit-owb.a (which was only amigaos native GUI code), and then giving him those parts from webkit itself like libwtf.a, libjsc.a and libwebcore.a, and he link them together with libwebkit-owb.a he compile on x1000. libwebkit-owb.a was just about 3megabytes of size.


@Walkero

Just in case you will be step in into the problems better to know it from start : do not try to build whole webkit with -gstabs or something you may need for debug , it will create for you few GIGABYTES libraries, which will not runs on OS4 at all. So for debugging you will need to rebuild only necessary files with -gstabs (manually) and then link them to final *.a to link into resulting exe.


As for 3d party libraries, from my own expirience, those libs mostly ./configure;make. Only few need changes. Like CURL for threading resolving. But for first test version, which you just want to show a window with content rendering in, pure "./configure;make" will be enough for almost everything.

If i were one who worry about new browser, then IMHO, based on past expirience i'll go that way:

1). compile whole webkit and test by internal tests that Endianes works, JSC works, etc. So we can be sure that Jacadaps's changes in webkit is fits well for os4 as well (there can be surely new bugs arises, like something wrong and works not as expected, etc).


2). Made a simple "test.cpp" , where i will just send "google.com" to webkit's internals, and read back answer from socket (via curl or whatever) so to see that data from google.com were taken back (mean webkit works).

3). Once this done, made whole webkit as class, or as library, or whatever. There also can be surprises from os4 side, like something will be not supported , or it will be "too big" to be shared class or whatever.

4). and then just simple open-window with argument in the shell a site to visit, and rendering it to window back.

5) And that all, browser done. All the other is just for GUI programmers, etc.

@kas1e

I think MultiViewer uses GPU memory above the 256MB.

@kas1e

Quote:

I actually did build webkit with a native compiler back in the days. And on a Sam440 too! It took the whole night, and I would sleep next to the machine to listen for drive noises. ;)

@alfkil

Quote:

What kind of motivation do you need?

@Antique

I need hugs and cuddles. And maybe a little bit of cash. And people shouting out of sheer joy. But first of all I need to set myself up for the task. That's gonna take a little while.

@alfkil

Ok I hug you and cuddle.
And I send you my sister's number.

I joke sorry

I think is correct that pay the open source developers.
But is impossible to change the world.

If possible, insert a publicity's banner in the browser. With a formula pay for remove

@alfkil

lol, that was funny!

As vagappc suggested, there should be a link withing browser for option to donate which will never expire, maybe in the About window, on top of it so it is not missed. All info and credits below. This might ensure continuous work on the browser and funding. Maybe even a nag popup once in a blue moon asking for donation? Just my two cents...

What about patreon?

@kas1e
Most of the points you mentioned are in our plan of what we wanna do. And when we have something tangible, we are going to inform you all to have a look.

@vagappc @levellord @Raziel
Just to make sure, what you propose is for alfkill's work, right? You do not talk about the WebKit initiative of the topic. Of course, alfkill deserves every hug and love from the community, and we should support him and persuade him to start working again on the QT browser.

For our work we plan to use a donation platform that will help, based on your support, to keep that project sustainable for continuous maintenance. We will inform you all about it when it is done.

I'd like to share with you guys some good news. Yesterday, after a lot of hard work, we reached one of our milestones. We managed to have the JavaScriptCore (JSC) library compiling, along with the test binaries.

Of course, as soon as this was done I tried the binaries on my system and the testapi binary, which checks the library with many different scenarios, passing most of them until a point where it crashes with a complain that has to do with pthread. The screenshot below shows some of the output.




Other test binaries are not running because they require the JIT to be enabled, which is not the case with this port.

For that outcome, we worked hard the past couple of months and we did a lot of digging to figure out why things are not working. Ryan (rjd324) helped a lot by going over and beyond and unblocking me in various situations, like for example the latest of his contribution to clib2 where he added necessary methods there. Andreas (afxgroup) was always helpful with unblocking me providing information and ideas. And of course, Jacek (jacadcaps) never complained about my emails, every time
was kind enough to reply and help me with my enquiries.

If you want to find more information on what happened and the problems we faced, you can read at https://github.com/walkero-gr/webkitty/issues/7 where I tried to document anything necessary. There is going to be a proper page on the project wiki, where I will summarize the needed information.

Also, we finalised, for now, the development environment for this project, and you can find info at https://github.com/walkero-gr/webkitty/wiki/Development-environment

Next steps
Of course, our work doesn't stop here. This is a long journey.
What I would like to do is to make the necessary changes so as to be able to compile it with newlib as well. If that is not possible, I will provide all the necessary information to the maintainer, so that missing parts can be added.

Along with that, we need to take a look at why the JSC breaks on pthread and if this is possible to be fixed.

And then we have to take a look at porting the rest of the WebKit engine.

Hope you enjoy this news and be sure that although we are a little bit silent about the port, this is because we are doing a lot of work on it.

@George
That a long road for sure, but, from my past experience can say that all the hard and boring work already done : you all know how to build the thing, how to compile the thing, how it structured, what kind of 3d party libs it uses and where, etc.

All the rest, will be more or less easy-logical in terms that you know what to do already. The only issues will be is facing with the problems inside the GCC, cLIB and the OS4 components like kernel.

But i am sure with Ryan helping with GCC fixes and Andrea helping improving CLIB2, that can be done till the having proper "webkit.library".

And the fact that Jasek do help answer questions, will be surely help a lot (if it wasn't a Fab helping me back in past, not sure that there ever was any Odyssey release for os4)

Thumby !

@walkero

JSC is alive!!!!! Yessssss

GREAT JOB

Congrats to everyone involved!

Good very good

@walkero and friends

Thanks for your initiative and drive to work on this project. This sort of thing gets an old Amigan excited.

@walkero

Really cool, I think this right way to go, just focus on JS, everything else, is trivial, WebKit has compiled many times. The JIT compiler probably need a lot of time to be understood, once someone understands it, I’m pretty sure some one can replace or fix it.

@walkero

It's great to read of your progress! Thanks walkero, rjd324,
afxgroup, jacadcaps and everyone working on the project.

Great little bit of holiday news.

:D

PJS