[webkit-dev] help with porting
Mike Emmel
mike.emmel at gmail.com
Fri May 23 10:06:47 PDT 2008
Look you can take the clutter code base and remove the clutter dependencies.
As far as cairo compile without any backed support.
You need at least a minimal event queue and timer support.
I'd suggest lib event
http://monkey.org/~provos/libevent/
Then you need at least a simple canvas object you can do this all in
Widget if you wish
track your bounds and your canvas object a cairo-surface in this case.
The clutter port is really close just unclutter it :)
This will render a single frame and fire the onload even and any
repaint requests from the server along
with timers. That all that has to happen. The only real trick is you
have to have real timers and delay
the callers of the timer function have to return before the timer fires.
On the build side I have sent patch to alp to build using configure without gtk.
The clutter port has similar patches. I just looked and the head
GNUMakefiles are not refactored.
If you can get a patch accepted to turn gtk into one of the ports
supported by configure then thats
a big win.
Finally its actually not all that hard to create a No-port but with
cairo and curl that will compile I've done it. There are
really only a handful of problematic headers and #ifdefs in the code
its quite close. I did not do
one without cairo and curl but for a long time I was running WebKit as
a generic shared library
with the port outside the webkit tree. I just got tired of mangled
merges. I'm sure others have done the
same its not that hard.
If you want to see whats going on then one approach is to put your
cairo surfaces in shared mem then
right a viewer or write them out as a png etc.
You could update a png on each run of the event loop. If you use
libevent then you can do a named pipe
anyway outside the scope :)
Attached is a Timer implementation that uses setitimer I think Pleyo
wrote it or maybe I wrote it :)
I don't remember. I don't think it ever showed up in the main tree.
In any case you could use this and a bit of select code to implement a
simple event loop without
using libevent if you wish. Or you could use glibs main loop but why ?
On Fri, May 23, 2008 at 6:28 AM, Luka Napotnik <luka.napotnik at gmail.com> wrote:
> Hm I see they made their own "widget" for clutter. It seems modifying
> the gobject class so it would be inherited form GdkPixmap should do the
> trick. I'll play with this for a while. Still it would be great for a
> clean cairo port without X. I'll investigate that later.
>
> Greets,
> Luka
>
> Dne 23.05.2008 (pet) ob 14:11 +0200 je Julien Sanchez zapisal(a):
>> Hello Luka,
>>
>> I used the following path from clutter repository:
>> http://svn.o-hand.com/view/clutter/trunk/clutter-webkit/webkit-frame-show-cairo.patch?rev=2031&view=markup
>>
>> As a rough prototype, I adapted an "OffscreenWebkit" class inspired from
>> the ClutterWebkitClass from clutter-webkit
>> (http://svn.o-hand.com/view/clutter/trunk/clutter-webkit/clutter-webkit.c?rev=2030&view=markup)
>>
>> and more especially in load_finished_cb:
>>
>> static void load_finished_cb (WebKitWebView *web_view,
>> WebKitWebFrame *frame,
>> OffscreenWebkit *webkit)
>> {
>> g_print ("load_finished_cb\n");
>> OffscreenWebkitPrivate *priv = OFFSCREEN_WEBKIT_GET_PRIVATE(webkit);
>> cairo_surface_t *surf = cairo_image_surface_create(CAIRO_FORMAT_RGB24,
>> priv->width, priv->height);
>> cairo_t* cr_surf = cairo_create(surf);
>> cairo_rectangle (cr_surf, 0, 0, priv->width, priv->height);
>> webkit_web_frame_show (frame, cr_surf);
>> cairo_surface_write_to_png(surf, "webkitsurf.png");
>> cairo_surface_destroy(surf);
>>
>> surf =
>> cairo_pdf_surface_create("webkitsurf.pdf", priv->width, priv->height);
>> cr_surf = cairo_create(surf);
>> cairo_rectangle (cr_surf, 0, 0, priv->width, priv->height);
>> webkit_web_frame_show (frame, cr_surf);
>> cairo_surface_show_page(surf);
>>
>> cairo_surface_finish(surf);
>> cairo_surface_destroy(surf);
>>
>> g_main_loop_quit(loop);
>> }
>>
>> It works but I wonder if it is possible to to the same without an X
>> server (I just tried with the gtk-directfb port :./configure
>> --enable-debug --with-target=directfb but it does not work. I don't know
>> how to use directfb and if it will be efficient.
>>
>> Julien
>>
>> Le vendredi 23 mai 2008 à 13:32 +0200, Luka Napotnik a écrit :
>> > Hello Julien.
>> >
>> > So you didn't draw the webkitview widget at all but stil managed to get
>> > a cairo drawing from the engine? If so, could you please tell me how did
>> > you do that?
>> >
>> > Greets,
>> > Luka
>> >
>> > Dne 23.05.2008 (pet) ob 12:58 +0200 je Julien Sanchez zapisal(a):
>> > > Hello,
>> > >
>> > > I'm interested too in such a port because I'm trying to render simple
>> > > html (no plugins or widgets) into image and pdf backends.
>> > > For the moment, I made a simple hack (inspired from Clutter project) to
>> > > render into a cairo surface. It works from the command line but it still
>> > > depends from X (and GTK) and I don't know where to begin to get rid of
>> > > these dependencies.
>> > >
>> > > Julien
>> > >
>> > > Le jeudi 22 mai 2008 à 09:30 -0700, Mike Emmel a écrit :
>> > > > Luka I don't think it makes a difference if your running a lot of
>> > > > thumbnails you would want to use gpu's some sort of render
>> > > > farm arrangement. My port does it as a result of the design not
>> > > > because of a strong desire to render with the cpu.
>> > > > Also for real world web pages your going to have problems with plugins
>> > > > which depend on X11 and native widget libraries.
>> > > >
>> > > > So although its possible with my port I can't see a single real
>> > > > problem that can be solved with this approach.
>> > > > Gtk/DirectFB will work for most pages if you have a flash port. Thats
>> > > > the number one stumbling block.
>> > > > I did my headless version of DirectFB for example to use the DirectFB
>> > > > video provider for the media tags.
>> > > > You can take other approaches but you would need to consider at a
>> > > > minimum flash and the media tags.
>> > > > For complete font support your going to have to use pango or go with
>> > > > the QT port but the QT port gets you back
>> > > > to the plugin issues if you don't use X11 and a lot of plugins use GTK so....
>> > > >
>> > > >
>> > > > As far as releasing I'm not in control of the release cycle except for
>> > > > creating delays as I work on stuff :(
>> > > > It should be released however some time this year.
>> > > >
>> > > > I obviously don't disagree with your idea in fact I worked hard to
>> > > > ensure my approach was adaptable so it could be used for these types
>> > > > of use cases so someday we will have what your looking for if things
>> > > > go well. I actually designed it to work
>> > > > with all the legacy use cases I mentioned but be flexible enough to
>> > > > transparently drop them when replacements without the legacy X11/Gtk
>> > > > dependencies become available. So soon a framework will be available
>> > > > to allow you to reverse software
>> > > > bloat but I've got no idea if software developers will accept it. I
>> > > > built it to deal with the problems that occur with our new embedded
>> > > > devices that have capabilities rivaling desktops where bloat is a huge
>> > > > problem. The fact it can do what your asking makes me confident the
>> > > > design is correct in fact it solves problems your not considering.
>> > > >
>> > > >
>> > > >
>> > > >
>> > > >
>> > > >
>> > > >
>> > > >
>> > > >
>> > > >
>> > > >
>> > > >
>> > > > On Thu, May 22, 2008 at 8:41 AM, Luka Napotnik <luka.napotnik at gmail.com> wrote:
>> > > > > Wow really? Could you share the port please. I've been looking for such
>> > > > > a port to save the cairo painting to a PNG image.
>> > > > >
>> > > > > Greets,
>> > > > > Luka
>> > > > >
>> > > > > Dne 22.05.2008 (čet) ob 07:41 -0700 je Mike Emmel zapisal(a):
>> > > > >> I actually have a WebKit port with no dependencies but Cairo.
>> > > > >>
>> > > > >>
>> > > > >>
>> > > > >> On Thu, May 22, 2008 at 7:02 AM, Luka Napotnik <luka.napotnik at gmail.com> wrote:
>> > > > >> > Hello Mike.
>> > > > >> >
>> > > > >> > What I need is a WebKit port that is independent of any display server
>> > > > >> > (X or a framebuffer). I only want to render the page to an image. And
>> > > > >> > since cairo is a great graphics library I think It's a good start.
>> > > > >> >
>> > > > >> > Greets,
>> > > > >> > Luka
>> > > > >> >
>> > > > >> > Dne 22.05.2008 (čet) ob 06:49 -0700 je Mike Emmel zapisal(a):
>> > > > >> >> Use the GTK DirectFB backend.
>> > > > >> >>
>> > > > >> >> I have a memory only system that I really need to get into the trunk.
>> > > > >> >> But if you have a graphics card in the system the fb0 will work.
>> > > > >> >>
>> > > > >> >> Its on my TODO to get the mem only system checked in and I can give
>> > > > >> >> you a patch in the mean time if its a issue. Also you can use the vnc driver
>> > > > >> >> as a virtual framebuffer.
>> > > > >> >>
>> > > > >> >> Also some of the XServers should work in a similar way so you can probably
>> > > > >> >> play the same trick with the right X11 server.
>> > > > >> >>
>> > > > >> >>
>> > > > >> >> On Thu, May 22, 2008 at 4:21 AM, Luka Napotnik <luka.napotnik at gmail.com> wrote:
>> > > > >> >> > Hello.
>> > > > >> >> >
>> > > > >> >> > I am interested in porting webkit to cairo for off-screen rendering
>> > > > >> >> > without a X server. As I cannot find any documents about porting to
>> > > > >> >> > other platform I would really appreciate if you could help me with some
>> > > > >> >> > hints about porting webkit.
>> > > > >> >> >
>> > > > >> >> > Greets,
>> > > > >> >> > Luka
>> > > > >> >> >
>> > > > >> >> > _______________________________________________
>> > > > >> >> > webkit-dev mailing list
>> > > > >> >> > webkit-dev at lists.webkit.org
>> > > > >> >> > http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>> > > > >> >> >
>> > > > >> >> >
>> > > > >> >
>> > > > >
>> > > > _______________________________________________
>> > > > webkit-dev mailing list
>> > > > webkit-dev at lists.webkit.org
>> > > > http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>> > > >
>> > >
>>
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: SharedTimerLinux.cpp
Type: text/x-c++src
Size: 4641 bytes
Desc: not available
Url : http://lists.webkit.org/pipermail/webkit-dev/attachments/20080523/2af41ca9/attachment.bin
More information about the webkit-dev
mailing list