Bug 49184

It is a policy in WebCore that layout is being postponed whenever possible, which leads to cases when the page has an incorrect/incomplete layout at the beginning of processing of a paint event. This is the case for example when JavaScript changes the style of a node such that its position or size changes as a result. Of course, during paint event processing the layout is completed, before rendering begins, thus what is painted is consistent with the changed layout, except that Qt restricts painting to the area that was marked as needing update before the paint event processing started, thus even though as a result of the layout change a larger/different area needs repaint, the user sees on the screen changes related only to the areas that were known as dirty and these changes are inconsistent with the previous image of the document and artifacts result. Later on, a second paint event may fix the issue, but in the mean time on slow systems, such as cell phones, this causes flicker. In some particular cases such as when paint events are dropped, or when the document image is transformed (i.e. scrolled) between the first and second painting, persistent artifacts may result. The painter used for painting is not clipped (at list if QGraphicsWebView is used), but painting happens on an intermediary canvas and only the initially dirty region is blitted ultimately to the screen. Given these constraints, the solutions I see to the problem are the following (all with performance impacts or interface changes): 1. Allow the paint method of QGraphicsItem to adjust the exposedRect to cover the newly dirtied areas and blit this entire new area to the screen: Advantage: Probably best performance. Disadvantage: Requires Qt API change. 2. Every time when there is a pending Layout dirty the entire WebKitView: Advantage: Minimized performance impact, no Qt Api change Disadvantage: It may be hard to track all cases of pending layout. 3. Indiscriminately dirty the entire WebKitView every time when there is a dirty portion of it. Advantage: It is easy to implement and reliably solves the artifacts problem (potentially 33 webkit bugs logged on the subject). Disadvantage: It may significantly reduce performance. 4. Do not postpone layout beyond yielding the WebCore thread. Advantage: Probably no heavier performance impact then solution 2, maybe even lighter. Disadvantage: Hard to implement. 5. Adding an extra View managed buffer, such that the entire QtGraphicsItem will be dirtied every time, but only necessary portions will be rendered onto the view managed buffer. Advantage: Easy to implement, safe. Disadvantage: Performance impact, memory usage. Reviewers, please comment on these proposals and help me pick one.