Bug 52702 – [GTK] No need to invalidate empty areas in ChromeClient::invalidateContentsAndWindow

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

[Joone Hur]

When rendering a web page, WebKitGtk+ invalidates empty areas too much. 
It causes unnecessary calls to GDK.

[Joone Hur]

Created attachment 79397 [details]
Proposed Patch

[Carlos Garcia Campos]

gdk_window_invalidate_rect() doesn't check whether the rectangle is empty, so the patch makes sense to me.

[Andreas Kling]

Comment on attachment 79397 [details]
Proposed Patch

r=me

[WebKit Commit Bot]

Comment on attachment 79397 [details]
Proposed Patch

Rejecting attachment 79397 [details] from commit-queue.

Failed to run "['./Tools/Scripts/webkit-patch', '--status-host=queues.webkit.org', '--bot-id=eseidel-cq-sl', 'bu..." exit_code: 2

Last 500 characters of output:
ests/css ....
http/tests/eventsource .......
http/tests/eventsource/workers .
http/tests/globalhistory ....
http/tests/history .............................
http/tests/incremental ......
http/tests/inspector-enabled .
http/tests/inspector ......
http/tests/inspector/extensions-resources-redirect.html -> failed

Exiting early after 1 failures. 21479 tests run.
418.29s total testing time

21478 test cases (99%) succeeded
1 test case (<1%) had incorrect layout
11 test cases (<1%) had stderr output

Full output: http://queues.webkit.org/results/7615202

[Joone Hur]

The above test fail is not relevant to this patch.
You can see the automatically generated bug from the commit-queue.
https://bugs.webkit.org/show_bug.cgi?id=52709

[WebKit Commit Bot]

Comment on attachment 79397 [details]
Proposed Patch

Clearing flags on attachment: 79397

Committed r76130: <http://trac.webkit.org/changeset/76130>

[WebKit Commit Bot]

All reviewed patches have been landed.  Closing bug.

[Eric Seidel (no email)]

(In reply to comment #5)
> The above test fail is not relevant to this patch.
> You can see the automatically generated bug from the commit-queue.
> https://bugs.webkit.org/show_bug.cgi?id=52709

Thanks.  The commit-queue runs the tests 3 times.  Twice with your patch and once w/o (if the first two runs failed).  In this case, the flaky test failed both times when you patch was applied, and then didn't fail when the tests ran w/o your patch.  So the queue had no choice but to (wrongly) assume it was your patch at fault.

Such is the cost of flaky tests!  Hopefully folks will continue to whittle down the number of flaky tests in the tree.

http://trac.webkit.org/browser/trunk/Tools/Scripts/webkitpy/tool/bot/commitqueuetask.py#L214