[WK2] TiledBackingStore: Problems while resizing of web view while page is not wholly loaded

• Component: WebKit2
• Status: NEW ---

[Mikhail Pozdnyakov]

Drawing area is frozen while the page is being loaded, so when the User resizes (extends) the view it looks ugly.
This should be solved probably by showing of default background (checked or some default colour) in the view areas that don't have contents yet.

[Kenneth Rohde Christiansen]

There are other issues, like the pinch etc use the values from the page currently being loaded.

And we cannot relayout or recalculate the viewport during load for the currently shown old page.

Maybe this pageTransition stuff isnt worth it.

[Andras Becsi]

This is probably the same issue also visible with tap-highlighting: the highlight-rect freezes during page transition and the hide animation does not finish running.

[Jocelyn Turcotte]

Please test with a release build before fixing this.

As far as I know this is only slowed down by painting which shouldn't take long. It is pretty slow in debug mostly because of the extra consistency checks in HashTable, last time I checked.

[Kenneth Rohde Christiansen]

(In reply to comment #3)
> Please test with a release build before fixing this.
> 
> As far as I know this is only slowed down by painting which shouldn't take long. It is pretty slow in debug mostly because of the extra consistency checks in HashTable, last time I checked.

This is tested with release build.

[Kenneth Rohde Christiansen]

(In reply to comment #2)
> This is probably the same issue also visible with tap-highlighting: the highlight-rect freezes during page transition and the hide animation does not finish running.

During the page transition we dont send event to the web page anymore (after patch by Mikhail) Is this still an issue?

[Andras Becsi]

(In reply to comment #5)
> (In reply to comment #2)
> > This is probably the same issue also visible with tap-highlighting: the highlight-rect freezes during page transition and the hide animation does not finish running.
> 
> During the page transition we dont send event to the web page anymore (after patch by Mikhail) Is this still an issue?

I think it is not related to the events, since the tap-highlight is triggered by the tap gesture recognizer and the issue is, that the hide-animation of the highlight overlay freezes when transition to the new page starts, eg. the highlight rect does not fade out completely.

This is still visible in Qt MiniBrowser on trunk.

[Jocelyn Turcotte]

(In reply to comment #0)
> Drawing area is frozen while the page is being loaded, so when the User resizes (extends) the view it looks ugly.
> This should be solved probably by showing of default background (checked or some default colour) in the view areas that don't have contents yet.

If I understand the issue correctly, since the TextureMapper doesn't paint anything on those pixels, it's the responsibility of the port to render the background it wants first. Qt's MiniBrowser has a dark grey background for example.

(In reply to comment #1)
> There are other issues, like the pinch etc use the values from the page currently being loaded.
> 
> And we cannot relayout or recalculate the viewport during load for the currently shown old page.
> 
> Maybe this pageTransition stuff isnt worth it.

The page transition is actually just an extra transition of a few frames (I'd say maximum 200ms) that compensates for the way that FrameView would itself block the rendering until it knows the proper scroll position to render when not using delegated scrolling.

There was already a freeze of the rendering happening between the provisional load start and the first layout of the new page, and it wouldn't be better to render the empty layouts we get meanwhile.

(In reply to comment #2)
> This is probably the same issue also visible with tap-highlighting: the highlight-rect freezes during page transition and the hide animation does not finish running.

I think that we shouldn't rely on the WebProcess to animate the tap highlighting, the overlay mechanism wasn't designed for that kind of purpose. Rects should be sent to the UI process and it should be the one rendering the animation.