[webkit-qt] QWebPage, scrollRequested and elements with fixed position

[johan.wikman at nokia.com]

Hi,

I'm using Qt 4.7.0 (4.7.0~git20100909-0maemo1+0m5 on N900 to be precise), and use QWebPage for loading web-pages and render the stuff into a QImage.

I listen on the scrollRequested and paintRequested signals and in the slot for the former I move the existing bitmap as requested and then explicitly render the exposed area using the main frame of the page. In the slot for the latter I collect the dirty rect into a dirty region and then render the region via the event loop.

This works fine, as long as the page does not contain elements with fixed position.

Namely, if I call QWebFrame::setScrollPosition() I will only get one scrollRequested signal, which will cause any fixed elements to be moved, just like everything else, but then I will not get an appropriate repaintRequested signal that would put the fixed element back where it should be. If a part of the fixed element happens to be in the exposed area, then that part will be renderered in the right place. Anyway, the end-result does not look good.

I was wondering why QGraphicsWebView does not suffer from anything similar, so I tried to see how things are renderered there.

In ChromeClientQt::scroll(...), platformPageClient()->scroll(...) is called before the scrollRequested signal is emitted. That scroll-call presumably (I've just looked at the code, havn't run this in the debugger) is on QGraphicsWebViewPrivate, which forwards it to QGraphicsWebView. QGraphicsWebView does not define scroll, so the call ends up in QGraphicsItem.

The documentation of QGraphicsItem::scroll(...) states:

"Note: Scrolling is only supported when QGraphicsItem::ItemCoordinateCache is enabled; in all other cases calling this function is equivalent to calling update(rect)."

ItemCoordinateCache is not enabled on QGraphicsWebView and indeed, it seems that every scrollRequested signal is followed by a paint-call where the exposedRect is the entire window.

As an experiment I enabled ItemCoordinateCache on QGraphicsWebView and the result was that every scrollRequested signal was no longer followed by a paint-call to paint the entire window, but only the exposed area. And then QGraphicsWebView started suffering from the same problem I explained above.

So, is this the way it is supposed to be or should you be able to do what you are asked to do by scrollRequested, also in the presence of elements with a fixed position? In a scrolling use-case of ours, moving the bitmap and rendering the exposed area takes 37ms, while rendering the whole thing takes 68ms.

Best regards,
  Johan