An Unseasonable Snowfall
A year or two ago I ported the Cocoa "CallJS" application to MFC for use with WebKit. The only feedback I ever got on the topic was a complaint that it would not build under the Visual Studio Express software many people used.
After seeing another few requests on the webkit-help mailing list for information on calling JavaScript from C++ (and vice-versa), I decided to dust off the old program and convert it to pure WINAPI calls so that VS Express would work with it.
Since my beloved Layered Window patches finally landed in WebKit, I also incorporated a transparent WebKit view floating over the main application window. Because I suck at art, Istole appropriated the Let It Snow animation example to give the transparent layer something to do.
Want to see what it looks like?
After seeing another few requests on the webkit-help mailing list for information on calling JavaScript from C++ (and vice-versa), I decided to dust off the old program and convert it to pure WINAPI calls so that VS Express would work with it.
Since my beloved Layered Window patches finally landed in WebKit, I also incorporated a transparent WebKit view floating over the main application window. Because I suck at art, I
Want to see what it looks like?
Comments
At the moment there isn't really a nice clean, open source, native WebKit port that is easily embeddable in a C++ application. By native, I mean focused on the latest Windows tech such as D2D, D3D etc, rather than OGL.
WinCairo - lacks hardware acceleration (from what I can tell) aswell as D2D and DW (I wonder if WinCairo would build against Mozilla's modified Cairo-with-d2d?)
Qt - abstraction layers and overall focus probably mean that it's never going to fulfil this (eg they added them removed a D3D painter). Plus it seems a pain to integrate Qt into an existing project and seems to be geared towards using their frameworks.
WinApple - proprietary components. I think they've wrapped up all the D3D stuff inside done kind of CG non-distributable?
WinGTK - similar story to Qt?
It seems to me that there is room for a native open source Windows WebKit port with the focus being on outdoing IE/Firefox etc.
WinCairo looks like a decent starting point for such a venture...
Are there any plans to work on hardware acceleration for the WinCairo port?
For example, using D3D for hardware accelerated composition and D2D for drawing (perhaps Mozilla's modified cairo-d2d would build against WinCairo?)
I've been looking for the open source equivalent of the Mac WebKit port, i.e. nice and easy to embed, native performance (no abstraction layers and using whatever is the predominant graphics API on Windows, i.e. DX) and there doesn't really seem to be anything fulfilling this role.
From what I can tell we have:
Apple Window port - proprietary components
Apple Cairo port - really nice, but lacking acceleration
Qt - native Windows performance isn't really going to be the focus (for example they got rid of the experimental D3D QPainter, which says it all)
Gtk - similar story to above, abstraction layers, not a windows-focused library, etc
Chrome - accelerated, but not using either DirectWrite or D2D. Plus you have to fully buy into the whole multi-process design, which is overkill for some situations. Being able to use WebKit directly is desirable.
I noticed a bug report in WebKit where hardware accelerated composition was being discussed for the Apple windows port, but I think (though I might be wrong) that WinCairo can't take advantage of that because its all tied-up with the proprietary Apple CoreGraphics wrapper/library/thing?
I am working on better hardware support as I write this. Most of the work has been done by the Mozilla team; I'm just working on integrating their changes back into the core Cairo archive so that all Cairo projects can benefit from them.
Even with these changes, there are still a number of WebKit internal changes that will likely be needed. I think the Mozilla Cairo understands Win32 (GDI) surfaces and Direct2D surfaces. Unfortunately, WebKit is (currently) built against an earlier Windows SDK, and does not make Direct2D available. Hopefully this will change in the near future.
I'm hoping that the Cairo surfaces can be handled in a backend-agnostic way, so that it can internally use Direct2D surfaces without WebKit having to know about them, but I'm not sure how feasible this is.
Good news about the hardware acceleration work, anyway.
Assuming the D2D hurdles can be overcome will that mean the port will get the DirectWrite goodness too? IMO the lack of this is something that is in danger of making the Windows WebKit-based browsers, including Chrome, look a bit dated.