Changes between Initial Version and Version 1 of QtWebKitForQt5

May 30, 2011 8:03:54 AM (10 years ago)
Simon Hausmann



  • QtWebKitForQt5

    v1 v1  
     1== Disclaimer ==
     3This is my scratch-pad for thoughts about QtWebKit for Qt 5. After spending plenty of time talking to different people, I'm
     4slowly exceeding the capacity of my brain and it is time to digest, summarize and write down some content :)
     6Please feel free to edit right away or add comments with prefix between the paragraphs ("JoeDoe: I think this is all complete rubbish.")
     8== QtWebKit for Qt 5 ==
     10We have learned a lot about WebKit2 in the past months, as well as mobile web development. With QtWebKit for
     11Qt 5 it is time to bring this experience to the main line:
     13    * QtWebKit for Qt 5 should make it easy to write great mobile web browsers.
     14    * QtWebKit for Qt 5 provides convenient APIs for creating Qt applications that embed and closely integrate with web content.
     16== Design ==
     18Qt5 will be an interesting foundation for QtWebKit. The changes in Qt 5 that affect QtWebKit the most are the move of
     19QWidget and related classes into a separate library as well as the introduction of Qt Quick 2 and the Qt Scene Graph as
     20the primary graphics/UI API.
     22Consequently the QtWebKit API should change:
     24   * The primary interface to the web engine should be through WebKit2.
     25   * A QML based UI component offers built-in handling for gestures, touch events and scrollbars (viewport).
     26   * Features like accelerated compositing, WebGL, inline video, etc. should work out of the box, without extra settings or configuration flags.
     27   * A minimal C++ API allows for fine-tuning certain parameters and potentially low-level hooks (for example controlling the web process creation)
     28   * The QWidget/QGraphicsView based WebKit1 API moves into a separate shared library that links against QtWebKit.
     30== Implementation Details ==
     32Let's look a bit closer into possible solutions to implement the proposed design:
     34=== WebKit2, Scene Graph, Tiling and Accelerated Compositing ===
     36The QML WebView should support tiling and AC out of the box and AC should not be anymore an afterthought
     37"on top of tiling" but we should be in a permanent state of accelerated compositing. Layers should support
     38tiling and the root tile set should just be a layer, to avoid expensive switching between AC and non-AC mode.
     40We need to determine the best way to integrate tiling / AC with the Qt scene graph. An initial pragmatic solution
     41would be to render the tiles and AC layers into an FBO first.
     43Another option would be to separate scene graph rendering from WebKit by rendering WebKit2 with raw OpenGL through
     44the Texture Mapper first and then the entire QML scene on top.
     46The approach requiring probably the most effort is to essentially re-implement WebKit2 UI-process sided AC on top of
     47the scene graph, i.e. let the web process serialize the layer & animation information to the UI process where the layer
     48tree is replicated in terms of scene graph geometry nodes and texture materials that are subject to animation.
     50=== Library split ===
     52Ideally the main QtWebKit library as well as the QtWebProcess won't link against the Qt widgets library. We should investigate
     53the option of moving all QWidget dependencies (like the old plugin code) out of WebCore and into a secondary QtWebKitWidgets
     54library that interfaces with WebCore through a platform plugin alike mechanism and hooks up top to implement QWebView/QGraphicsWebView.
     55In such a design, WebCore would paint primarily with the raster paint engine and load all images in QImage objects instead of QPixmaps.
     57=== WebGL ===
     59For an efficient WebGL implementation we could either
     61   1) Use OpenGL directly in the web process, render into an FBO and implement cross-process texture sharing for AC
     65   2) Serialize the OpenGL commands and execute them on the UI process side
     67Some research is needed here, but option 1) would have the additional benefit of also simplifying the video implementation
     68due to the texture sharing.
     70=== Video ===
     72In order to render embedded videos efficiently and provide seamless transitions to fullscreen playback, we require from the platform
     73the ability to render video into textures. For fullscreen playback we should piggy-back on the fullscreen element feature in WebCore/WebKit2
     74that integrates with AC. The video texture becomes the root layer and the controls live in their own layer on top.