Bug 89012 – [Qt] Create an extra atlas when there is no available buffer space.

• Status: RESOLVED
• Resolution: FIXED
• Component: WebKit Qt

[Alexis Menard (darktears)]

[Qt] Create an extra atlas when there no available buffer space.

[Alexis Menard (darktears)]

Created attachment 147342 [details]
Patch

[Jocelyn Turcotte]

Comment on attachment 147342 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=147342&action=review

> Source/WebKit2/ChangeLog:3
> +        [Qt] Create an extra atlas when there no available buffer space.

...when there is no...

> Source/WebKit2/ChangeLog:10
> +        are updated. It can happen that there no available buffer space for
> +        the current atlas used. In that case we can create a new one. One

"for the current atlas."? "for the currently used atlas."?

Looks fine to me otherwise.

[Jocelyn Turcotte]

I'll let No'am have a look if he's around.

[Alexis Menard (darktears)]

Created attachment 147354 [details]
Patch

[Noam Rosenthal]

Comment on attachment 147354 [details]
Patch

We should only enable this for desktop, with some settings flag, or a build flag. Otherwise we're making our scratch-buffer memory usage unpredictable.

[Alexis Menard (darktears)]

(In reply to comment #5)
> (From update of attachment 147354 [details])
> We should only enable this for desktop, with some settings flag, or a build flag. Otherwise we're making our scratch-buffer memory usage unpredictable.

It fixes an horrible bug that could totally happen where the drawing surface is big, and not necessarily on a desktop platform. It's not like we see checkerboard or something like that, we simply don't repaint some tiles for a while, making the scrolling just plainly horrible and buggy.

What about a compile flag where you specify the scratch buffer memory value like how many time we will create an atlas of 2000.

[Alexis Menard (darktears)]

(In reply to comment #6)
> (In reply to comment #5)
> > (From update of attachment 147354 [details] [details])
> > We should only enable this for desktop, with some settings flag, or a build flag. Otherwise we're making our scratch-buffer memory usage unpredictable.
> 
> It fixes an horrible bug that could totally happen where the drawing surface is big, and not necessarily on a desktop platform. It's not like we see checkerboard or something like that, we simply don't repaint some tiles for a while, making the scrolling just plainly horrible and buggy.
> 
> What about a compile flag where you specify the scratch buffer memory value like how many time we will create an atlas of 2000.

Also having the default case to be buggy is not really an option.

[Jocelyn Turcotte]

(In reply to comment #7)
> Also having the default case to be buggy is not really an option.

I agree, I think that it's much better if the default behavior on any platform is perfectly rendered.
If a platform wants to make sure that those 2MB of extra RAM are not allocated, the compile flag should be the exception and not the other way around.

Right now this causes tearing on the non-desktop view as well, during full-page renders like page loads, large document modifications, etc.

[Noam Rosenthal]

Comment on attachment 147354 [details]
Patch

OK, I agree with the comments.

[WebKit Review Bot]

Comment on attachment 147354 [details]
Patch

Clearing flags on attachment: 147354

Committed r120705: <http://trac.webkit.org/changeset/120705>

[WebKit Review Bot]

All reviewed patches have been landed.  Closing bug.