QtWebKit code camp 08-10.12.2009

More than 30 developers gathered together for QtWebKit code camp in Wiesbaden, Germany.

Intro & general presentations

In the beginning there were three presentations:

• Henri Haverinen: QtWebKit roadmapping & using ​Qt Jira
• Kenneth Christiansen: How Web and ​QML fit together
• Akos Kiss: WebKit related activities at the University of Szeged​

After that people were split into five work stream: Performance & Architecture, User Interface, JavaScriptCore, QA and Relasing & Roadmapping

Performance & Architecture

1st Day

• Antti is talking about tile based rendering. A working prototype is using QImage to paint in a thread. To make it general usable and accelerate Qt needs to gain the ability to draw to a QPixmap from different threads. One of the limitations will be handling certain CSS attributes that will be ignored just like the iPhone, WebOS and such. It was discussed if tiling should be supported for QWebView and QWebGraphicsView or only for the QWebGraphicsView. We have not drawn a conclusion.

• ​Presentation on how to support JavaScript programmers to see what is going on. Currently a JavaScript API to expose information about painting is exposed. This API is similiar to the Mozilla mozAfterPaint Event. This way a JavaScript developer can see which content will be redrawn due his code. Another thing is to export the FPS count for drawing to the JavaScript developer. This somehow relates to the WebTime effort of the W3C. In the future we will need a heap profiler that will show the heap usage for each callframe of the JavaScript execution and finally we need the ability to do this on the device and get the data on the host.

• BenjaminP was talking about plans for Qt4.7 to regularily run benchmarks during the development cycle and to automate and store these results.

• We were talking about OOM handling and if we really want to check each allocation vs. just getting killed by the OS vs. getting signals from the OS and then stop loading. The second part was sharing experience about the S60 port and the mainr eason the browser went out of memory. Holger speculated it was due images but from their experience it was mostly due JavaScript code. The conclusion somehow was to either get properly killed from the OS or to get a signal from the allocator/system that will stop loading and is freeing caches.

• Zoltan was talking about a new valgrind skin called ​freya (​presentation) to instrument memory usage including showing how much and who was allocating the memory. The special thing about freya is that it has a powerful configuration file that allows to combine various call frames, or omit certain things that are not interesting. The biggest limitation for him is that freya and the JavaScript JIT refuse to cooperate.

2nd Day

• Holger was talking about the QtWebKitPerformanceWork and QtWebKitPerformanceUtilities and how the can be used to measure Qt performance. The biggest shortcoming is the high variation seen when running the test. E.g. the tst_cycler is running for about 59 seconds on Holger's machine but there can be about a second difference from run to run. QBENCHMARK could and should be extended to provider better information about the variation. One comment was to use bandwidth limitation on the localhost between the http_server and the web browser and check if the numbers get more stable.
• We shortly discussed the RGB16 approach to save some memory by color converting RGB32 images to RGB16, specially on symbian a 16bit backingstore exists and all the painting can be done in 16 bit. In an older measurement of the page loading tests this could save about 2MB in the peek ​#29279.
• We shortly discussed using WebCore/platform/image-decoders. The downsampling is a feature some of us would like to use, also the performance appears to be better. We should explore using them ​#32410.

3rd Day

• Holger is MIA in the morning... claimed to be sick
• BenjaminP and Noam look into QtWebKit's CSS Animation speed and see we have a clip region with 800 rects... A quick test shows a nice improvement. The quick change is in the GraphicsContext on how we clip the paths.

• Holger talks with Zoltan of Szeged about performance tuning. Both find out that current focus is more on performance and that both parties more or less see the same in profile reports. CSS and JS parsing is dominating our page loading. Szeged's idea is to try a hand written parser for comparison. Some more coordination is needed, for the next few months there is no overlap in work though.

User Interface

1st Day

• Discussed interfacing of touch events with WebKit.

2nd Day

Form controls issues:

• Multiple selection list box has too small items in order to be selectable on a touch device. Different platforms and devices have specialized controls that allow comfortable user interaction. Currently WebKit does not allow usage of such controls. Multiple selection list box shall instantiate the appropriate QtControl upon focus. (Carol Szabo, cszabo1)
  • Determine the appropriate control.
• There are websites that show simulated popup menus upon hovering over a link, but clicking on the link takes the user to a new page. The desired user experience for a touch device is that generally touching focusable controls results in an emulated mouse click, but for links as described above the first touch should result only in hovering, only the second touch should result in a click.
  • Support hover without click on touch (Misha Tyutyunik).
• WAP CSS can specify restrictions to acceptable characters in an edit box. This could be useful in assigning actions to keypresses on devices with limited keyboards. I.e. if an edit control only accepts numeric keyboard should act as a numeric only keyboard, versus having the first key press result in letters being generated. (Carol Szabo, cszabo1)
• Find closest focusable node to point (Joe Ligman)
• List focusable nodes that intersect a given rectangle. (Joe Ligman)
• Ability to select items from a simulated dropdown list while an edit box has the focus. (Misha Tyutyunik)
  • Solution 1: Change the way the editbox is exited to not exit on down if the JavaScript handles the down key and makes changes to the document.
  • Solution 2: Change the editbox to exit only on long page down if there is a handler for the key in JavaScript or another solution for releaving the down key from the exit edit box action if needed.
• Adding the ability to scroll WebElements (Joe Ligman)
• Having the virtual keyboard send key events to WebCore. (Joe Ligman)
• Adding recursive scrolling to QWebFrame. (Joe Ligman)
• Styling of Form Controls (Carol Szabo, cszabo1)

3rd Day

• No activity for this group.

Java Script Core

1st Day

• Presentations
  • Loadable Abstract Syntax Tree (for JavaScript source code)
  • JIT in nutshell
  • About QtScript
  • Improving Garbage Collector (when we close a widget, we should regain memory)
  • Regular Expression Engine

2nd day

• very long discussion about how JavaScriptCore works (all the steps from parsing to JIT-ing)
  • Share our knowledge with each other
• QtScript internals (and examples)

3rd day

• Debugging and profiling in WebKit
• Discussions how we can improve WebKit's performance

QA

Informal presentation with discussion:

• Andras Becsi (bbandix): Problems with the current Qt DRT, + a tool to monitor and query historic test results (pdf​)
• Gabor Rapcsanyi (rgabor): Current buildbot setup and the future upgrade possibilities (pdf​)
• Csaba Osztrogonac (ossy): Qt build infrastructure and problems with incremental builds
• Tor Arne Vestbø (torarne): Cross platform layout-test results using SVG-fonts and automation of interpreting results

The discussion spawned off a few action points:

• Use automated tools to parse test results and give us more information about where we are
• Split of Qt buildbot into build and tests stages (makes it easier to detect Qt build breaks)
• Fix the Qt incremental build to detect dependencies in generated sources correctly
• Try to use SVG fonts to get the same results on mac,win,linux (++)

Roadmap & Releasing