Bug 206662 – [GTK] Reduce the maximum time we wait for draw events in DrawingMonitor

• Status: RESOLVED
• Resolution: FIXED
• Component: WebKitGTK

[Carlos Garcia Campos]

1 second is too much, we can wait up to 100_ms instead and wait for the next frame after 16_ms. We should also ensure there's a draw event since this is called from dispatchAfterEnsuringDrawing().

[Carlos Garcia Campos]

Created attachment 388541 [details]
Patch

[Carlos Alberto Lopez Perez]

Comment on attachment 388541 [details]
Patch

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

r=me

> Source/WebKit/UIProcess/CoordinatedGraphics/DrawingAreaProxyCoordinatedGraphics.cpp:413
> +    gtk_widget_queue_draw(m_webPage.viewWidget());

why this was not needed before?

[Carlos Garcia Campos]

Committed r255060: <https://trac.webkit.org/changeset/255060>

[Carlos Garcia Campos]

(In reply to Carlos Alberto Lopez Perez from comment #2)
> Comment on attachment 388541 [details]
> Patch
> 
> View in context:
> https://bugs.webkit.org/attachment.cgi?id=388541&action=review
> 
> r=me
> 
> > Source/WebKit/UIProcess/CoordinatedGraphics/DrawingAreaProxyCoordinatedGraphics.cpp:413
> > +    gtk_widget_queue_draw(m_webPage.viewWidget());
> 
> why this was not needed before?

In some cases, like when there's an animation or after a force repaint, there's already a draw scheduled. When there wasn't we ended up waiting 1 second. Now we ensure a draw, like expected. It doesn't hurt if there was a draw already scheduled.