NetRider - a Webkit based browser with an FLTK GUI

[Georg Potthast]

I just posted the first beta version of my Internet browser called NetRider:

https://sourceforge.net/projects/netrider/

On this site there are a few screenshots of this browser.

It is written in FLTK providing a GUI for the WebKit library. So rendering
works quite well and allows you to surf the Internet like other
WebKit based browsers.

I developed it using an openSUSE distribution and it compiles quite well there.

However, WebKit and NetRider are provided as source code. If all goes well it
will take you up to one hour to compile the browser.

I called my modified version of WebKit that I used for NetRider the WKCCC port.
This library extends WebKit with a C++ API. No FLTK is required for the WKCCC library.
The WKCCC library shall be extended to provide a C API as well, therefore the name.

The NetRider browser depends on FLTK of cause.

Not working yet in NetRider is file transfer, plugin support, audio/video, cookies, ...

The package includes an INSTALL file which describes how to compile NetRider
and WKCCC.

I could not find any beta testers yet so please report any issues or tell me if
you like it.

Georg

[Sanel Zukan]

Hi Georg,

This is absolutely amazing! I presume you added FLTK as drawing
backend; how hard was to do that?

Also, I'm interested in startup/drawing speed; can you share some
details behind it?

> I called my modified version of WebKit that I used for NetRider the
> WKCCC port.

What have you modified? I was assuming that WebKit is designed so
drawing backends could be easily added...

Best,
S.

[Ingwie Phoenix]

Hey!

That sounds like a very interesting project to me. I was originally going to use Chromium’s source tree in order to utilize Webkit and V8 („Blink“) for a project that I wanted to combine with FLTK. Since Webkit has some JS stuff integrated, can you tell me which JS engine it actually is, and how hard it was for you to incooperate?

How extensible is WebKit thru your WKCCC library? If this is a more lightweight solution than using Chromium (libchromiumcontents), I might actually change base.

Kind regards, Ingwie.

--
You received this message because you are subscribed to the Google Groups "fltk.general" group.
To unsubscribe from this group and stop receiving emails from it, send an email to fltkgeneral...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Georg Potthast]

Hi Sanel,

I suggest that you download the package and take a look at NetRider and the WKCCCWebLauncher test application. Then you can evaluate how hard it is. I think WKCCC makes it relatively easy. I did not make any speed tests it seems pretty much as fast as other browsers. Provided you do not take advantage of multi-processor environments like Chrome does.

There is no defined and documented WebKit API used by all. Every available port has implemented its own API, so you have several different ones. WKCCC provides a simple API which I still have to document.

Georg

[Georg Potthast]

Hi Ingwie,

WKCCC uses JavaScriptCore which is included in WebKit. So it was not hard at all to incorporate that.

WKCCC extends WebKit with an API that allows application programs to embed WebKit in e.g. FLTK applications. The API has been written so far that I could implement the NetRider browser.

Making WebKit lightweight - I do not know to what extend that is possible. It has a lot of dependencies. Currently I concentrated on getting it to work and made no evalutions how to shrink the package. The download is 40 MB now.

Georg

[ca...@gmx.com]

Hi,

Well this is quite the coincidence. It just so happens that I too have ported Webkit to FLTK a few weeks ago!

http://i58.tinypic.com/14ak9ac.png

https://github.com/clbr/webkitfltk

I wasn't going to announce it until I had a browser ready, but seeing another, we're clearly duplicating work here. I'll take a look at your port soon, see where they differ and so on.

The main points of my port:

- Linux-exclusive

- as light as possible. No Qt, Gtk, soup. It uses curl and cairo, with the biggest offender being icu

- slightly different philosophy with SSL, audio, video, and tracking

- aiming for performance and low RAM use

(warning: every version of gcc able to build webkit has a bug where it miscompiles the hash function using -O2 or higher; reported to gcc bugzilla, but until it's fixed or a workaround is found, don't do an optimized build)

@Ingwie

Webkit is by definition lighter than Chromium, as when you embed Chromium you get the whole browser logic, with Webkit you get a web widget to build upon. Chromium also includes a ton of modified libraries in its codebase, while webkit prefers to use system copies.

@Ian, George

Now you see why I need ctrl-tab in my application ;) It's the most often used shortcut in a browser.

@Sanel

I can only speak for my port. The widget toolkit is not a drawing backend, cairo is. The toolkit is only used to render un-css-styled widgets to the drawing surface, giving that "default look" for a platform, but is not really visible in many modern webpages.

The remainder is of course all the integration: making it a nice FLTK widget, and exposing all methods needed to build a browser.

As for how hard, it took me three weeks of work to do the grunt of the port. Webkit is a 5.6 million line codebase, and almost completely uncommented. I did more head-meet-desk on the first week than I'd like. It's not really made any easier by the sheer size of the thing, with a non-debug build requiring gigabytes of space and taking hours to build.

The parts I wanted to use, curl and cairo, had some amounts of bitrot, as no major platform uses either. The curl module is only used by some hobbyists on Windows, and so it was fairly broken on Linux when I started. The cairo module is used by gtk+, but no gtk-webkit browser has much market share, and it too had some bugs. Safari uses Apple's frameworks on all platforms, and Google is long gone with their Blink engine and Aura toolkit.

After that I've now spent another three weeks on the browser application. It's looking pretty nice, but still missing a lot of functionality before I can release a first alpha.

Re startup speed, the binary is close to 100mb, so first start from HD takes something like 0.8s. Warm caches it starts in < 100ms, which is quite acceptable to me. I've not yet targeted its size in any major way, but I estimate the final version may be able to reach 60mb or lower. Webkit alone takes 40mb, icu close to 20mb, the browser app a pittance in comparison.

- Lauri

[Ingwie Phoenix]

This is awesome! This could almost replace the Chromium part in my plan for Phoenix Engine and reduce the work I would have to do for the bridging part!

So tell me, which JS engine does your version use? JSC or V8?

[Sanel Zukan]

Hi Lauri,

We can freely call this month a 'Webkit Month'; two ports of Webkit
isn't a small thing :D Congratulations for this!

> I can only speak for my port. The widget toolkit is not a drawing
> backend, cairo is. The toolkit is only used to render un-css-styled
> widgets to the drawing surface, giving that "default look" for a
> platform, but is not really visible in many modern webpages.

Thanks for explanation. I'm curious, your distribution is way smaller
than George pull; what exactly you removed? I'll presume George took
unmodified Webkit tree.

I'm having some issues with the build. Push on github caused some
scripts to lose executable flag and after quick fix, I'm getting this:

make: Entering directory `Source/JavaScriptCore'
offlineasm/generate_offset_extractor.rb -I. llint/LowLevelInterpreter.asm \
LLIntDesiredOffsets.h
offlineasm: Parsing llint/LowLevelInterpreter.asm and creating offset extractor LLIntDesiredOffsets.h.
Source/JavaScriptCore/offlineasm/self_hash.rb:57:in `read': No such file or directory - llint/InitBytecodes.asm (Errno::ENOENT)
from Source/JavaScriptCore/offlineasm/self_hash.rb:57:in `block in fileListHash'
from Source/JavaScriptCore/offlineasm/self_hash.rb:55:in `each'
from Source/JavaScriptCore/offlineasm/self_hash.rb:55:in `fileListHash'
from Source/JavaScriptCore/offlineasm/parser.rb:782:in `parseHash'
from offlineasm/generate_offset_extractor.rb:51:in `<main>'
make: *** [LLIntDesiredOffsets.h] Error 1

Any idea?

Best,
Sanel

[Lauri Kasanen]

On Mon, 21 Jul 2014 13:40:29 +0200
Sanel Zukan wrote:

> Thanks for explanation. I'm curious, your distribution is way smaller
> than George pull; what exactly you removed? I'll presume George took
> unmodified Webkit tree.

I removed the various tools not needed, as well as the gigabytes of
tests (this is a surface port, in that it can't really cause any new
breakage in layout tests).

> I'm having some issues with the build. Push on github caused some
> scripts to lose executable flag and after quick fix, I'm getting this:
>
> make: Entering directory `Source/JavaScriptCore'
> offlineasm/generate_offset_extractor.rb -I. llint/LowLevelInterpreter.asm \
> LLIntDesiredOffsets.h
> offlineasm: Parsing llint/LowLevelInterpreter.asm and creating offset extractor LLIntDesiredOffsets.h.
> Source/JavaScriptCore/offlineasm/self_hash.rb:57:in `read': No such file or directory - llint/InitBytecodes.asm (Errno::ENOENT)
> from Source/JavaScriptCore/offlineasm/self_hash.rb:57:in `block in fileListHash'
> from Source/JavaScriptCore/offlineasm/self_hash.rb:55:in `each'
> from Source/JavaScriptCore/offlineasm/self_hash.rb:55:in `fileListHash'
> from Source/JavaScriptCore/offlineasm/parser.rb:782:in `parseHash'
> from offlineasm/generate_offset_extractor.rb:51:in `<main>'
> make: *** [LLIntDesiredOffsets.h] Error 1
>
> Any idea?

You should set the RUBY, PERL and PYTHON variables before running make.
There's currently no autodetection for them. If it still fails, try to
find which file it's looking for.

- Lauri

[Lauri Kasanen]

On Sat, 19 Jul 2014 01:37:06 +0200
Ingwie Phoenix wrote:

> This is awesome! This could almost replace the Chromium part in my plan for Phoenix Engine and reduce the work I would have to do for the bridging part!
>
> So tell me, which JS engine does your version use? JSC or V8?

It uses JavaScriptCore, the native choice for webkit. I should note the
JIT is currently disabled, it caused way too many crashes - JS is only
interpreted at the moment.

- Lauri

[Georg Potthast]

This is really a coincidence! I posted my first beta on the 20th of June and Lauri has apparently started on the 19th of June, one day before that.

WebKitGTK has been around for years but there was no WebKit port for FLTK - now two projects start at about the same time.

Georg

[Lauri Kasanen]

Hi,

I've taken a look at the differences between WKCCC and WebkitFLTK.
WebkitFLTK seems to be more complete.

WKCCC:
- uses Skia software rendering
- based on Webkit from 2011
- native (un-css-styled) widgets, scrollbars, a few other things not
yet implemented
- no platform dependencies

WebkitFLTK:
- uses XRender-accelerated cairo, including the final blit to the window
- currently based on Webkit from June
- still misses functionality from a full browser engine, but is farther
along
- requires Linux, X11

The GPU-accelerated blit was some five-seven times faster than a
software blit from a cairo sw surface when I implemented it.
Rendering with XRender vs sw seems to be under 2x faster.

Georg, what platforms do you target?

- Lauri

[Georg Potthast]

>WebkitFLTK seems to be more complete.

- wait for the next release ;-)
- I usually try to come up with something working quickly so to learn how
many people are interested in the solution. There were only a few downloads
and I know only of one user apart of me that got it to run -> Laura, who ported it to MinGW.

Compiling the source code takes a long time and every distribution seems to have different requirements
and libraries installed. So I understand that people keep their existing browser. ;-)

I am making the WKCCC library independent of FLTK so it can also be used with other
toolkits and applications. Now I have made a WebLauncher application in SDL that is using WKCCC.
Plus an unfinished print web page to PDF command line application that needs just c++. Skia supports this application.

I target Linux and Windows(MinGW). So far I did not look into rendering speed and
worked on other issues. Google uses skia since it used to be faster than cairo.

Georg

[Dmitrij K]

Georg, Lauri,

I wish luck you with yours projects.

PS: Do you have examples of using its ?

[Georg Potthast]

My package includes the NetRider browser which makes use of the library libwebkit_wkccc.so which is the WebKit code compiled into a shared library.

[Lauri Kasanen]

The browser I have is still under development, but there's a web
launcher included (WebKit/fltk/testapp).

- Lauri