wiki:QtWebKitGraphics

Version 1 (modified by noam.rosenthal@nokia.com, 14 years ago) (diff)

--

QtWebkit and Graphics

This page holds tips for web developers on how to optimize their web-code for QtWebkit's rendering pipeline. The philosophy behind those performance tips is that web technologies in general are meant for dynamic content and not for dynamic UI. Therefore, most of the HTML and CSS features are optimized for exactly that. When something is slow, ask yourself: am I trying to solve a dynamic-UI problem with a tool meant for dynamic-content? The good news is that CSS has enough capabilities for dynamic UI, even if they're not as smooth to use.

General graphics performance guidelines

Don't mess with the DOM

DOM manipulation is generally slow. The DOM is optimized for content changes, not for UI changes. If your web app moves between a list screen and a details screen, for example, it's better to have both of them ready in the DOM, hide the first one and show the second one, changing just the parts of the dialog that need changing due to the content being different. If moving between screens is slow, look for the DOM manipulations.

The CSS box model

The CSS box model is a concept from the world of content and not from the world of GUI. Everything from the CSS box model world (margin, padding, background, outline, border) should not be modified, for example, inside an animation, or in a performance-heavy task. If you need a dynamic image to be behind a static image, for example, a common pitfall is to have one image and change its background's URL or position using CSS. There are about 3 ways that are faster than that:

  • two different images
  • :after {content} or :before {content}
  • use negative z-index

So, CSS box model to decorate dynamic content - transforms and regular images for dynamic UI.

The $ is going to cost you

This is the most important performance tip. Sometimes it's tempting to create high-level object-oriented nicely-designed Javascript libraries on top of the core Webkit that make the application code look nicer (like Dojo or jQuery, hence the $). This is fun and productive, but also dangerous. That's because when you get to a performance problem, now you have layers on layers of code to go through until you find the where it comes from, and if you fix it you might have layers and layers of regressions. Abstractions like that are good when you know the scope of your problem - which might be the case for browser-compatible websites - but for (embedded) web-based UIs this is usually not the case.

If you think about what those libraries really give you, it's browser compatibility, rapid DOM element selection, and effects. Browser compatibility was discussed before. rapid DOM selection can be done with document.querySelector or document.querySelectorAll, which are much faster than the browser-compatible functions. effects, if can't be expressed with CSS animations, would probably end up being slow anyway.

Accelerated compositing

Accelerated compositing is (at the time of writing this) a new feature in webkit trunk, and therefore is not fully stable yet. Accelerated compositing is disabled by default. To enable it, you need to use a QGraphicsWebView, and set a QWebSettings flag:

myWebSettings->setAttribute(QWebSettings::AcceleratedCompositingEnabled, true);

Accelerated compositing doesn't magically accelerate everything. To make use of it, the web developer has to use CSS3 animations (-webkit-transition / -webkit-animation), and only animate the -webkit-transform or opacity attributes. Animating left, margin, width or any other attribute (mainly the ones related to the CSS box model) will not be accelerated: because the box model would have to make expensive calculations for each frame. Note that animating -webkit-transform and opacity should be very good for plenty of use cases - scrolling, for example, can be made very fast like this: (note that this is just a conceptual approach and not reusable code):

<div id="viewport" style="overflow: hidden">
  <div id="content" style="-webkit-transition-property: -webkit-transform">
    ... whatever ...
  </div>
</div>
<script>
  function scrollMe()
  {
    content.webkitTransform = "translate(0, 10px";
  }
</script>

Again, this feature is not yet stable but the web developers should know in advance what would and wouldn't be accelerated when using it. Also, 3D is not fully supported by QtWebkit as of yet, mainly the preserves-3D CSS attribute.

Good luck!

Attachments (1)

Download all attachments as: .zip