Bug 20885 - Use m_everHadLayout in RenderObject::checkForRepaintDuringLayout()
Summary: Use m_everHadLayout in RenderObject::checkForRepaintDuringLayout()
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: Layout and Rendering (show other bugs)
Version: 528+ (Nightly build)
Hardware: Mac OS X 10.5
: P3 Minor
Assignee: Eric Seidel (no email)
URL:
Keywords:
Depends on:
Blocks: 92800
  Show dependency treegraph
 
Reported: 2008-09-16 10:39 PDT by mitz
Modified: 2012-08-09 00:59 PDT (History)
6 users (show)

See Also:


Attachments
wip, I expect the cr-ews will see some pixel failures (1.64 KB, patch)
2012-08-02 01:16 PDT, Eric Seidel (no email)
no flags Details | Formatted Diff | Diff
Archive of layout-test-results from gce-cr-linux-03 (1.09 MB, application/zip)
2012-08-02 01:51 PDT, WebKit Review Bot
no flags Details
Should fix SVG, but may have other bugs (3.42 KB, patch)
2012-08-06 16:23 PDT, Eric Seidel (no email)
no flags Details | Formatted Diff | Diff
Archive of layout-test-results from gce-cr-linux-07 (596.67 KB, application/zip)
2012-08-06 19:48 PDT, WebKit Review Bot
no flags Details
Patch (46.72 KB, patch)
2012-08-06 23:53 PDT, Eric Seidel (no email)
no flags Details | Formatted Diff | Diff
Archive of layout-test-results from gce-cr-linux-03 (356.40 KB, application/zip)
2012-08-07 03:29 PDT, WebKit Review Bot
no flags Details
Patch including more updated pixel results (96.18 KB, patch)
2012-08-07 12:38 PDT, Eric Seidel (no email)
no flags Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description mitz 2008-09-16 10:39:12 PDT
RenderBlock suppresses repainting during layout if m_everHadLayout is false. As the FIXME in RenderObject::checkForRepaintDuringLayout() says, this should be generalized to all RenderObjects.
Comment 1 Eric Seidel (no email) 2012-08-02 01:16:35 PDT
Created attachment 156001 [details]
wip, I expect the cr-ews will see some pixel failures
Comment 2 WebKit Review Bot 2012-08-02 01:51:45 PDT
Comment on attachment 156001 [details]
wip, I expect the cr-ews will see some pixel failures

Attachment 156001 [details] did not pass chromium-ews (chromium-xvfb):
Output: http://queues.webkit.org/results/13424131

New failing tests:
svg/hixie/perf/004.xml
svg/hixie/perf/005.xml
svg/custom/js-late-marker-creation.svg
svg/carto.net/window.svg
svg/custom/use-detach.svg
svg/custom/js-late-clipPath-and-object-creation.svg
svg/custom/js-late-mask-creation.svg
svg/hixie/perf/006.xml
svg/custom/js-late-mask-and-object-creation.svg
svg/custom/js-late-clipPath-creation.svg
Comment 3 WebKit Review Bot 2012-08-02 01:51:48 PDT
Created attachment 156007 [details]
Archive of layout-test-results from gce-cr-linux-03

The attached test failures were seen while running run-webkit-tests on the chromium-ews.
Bot: gce-cr-linux-03  Port: <class 'webkitpy.common.config.ports.ChromiumXVFBPort'>  Platform: Linux-2.6.39-gcg-201203291735-x86_64-with-Ubuntu-10.04-lucid
Comment 4 Eric Seidel (no email) 2012-08-02 02:16:29 PDT
Very interesting.  I'll look into the failures more in the morning, but these look identical to failures seen in bug 92800.  I believe SVG just isn't ready for this optimization as I think this optimization depends on parents telling their children to do a full repaint when they do their first layout, but I'm not yet sure.
Comment 5 Eric Seidel (no email) 2012-08-06 16:23:50 PDT
Created attachment 156786 [details]
Should fix SVG, but may have other bugs
Comment 6 WebKit Review Bot 2012-08-06 19:48:29 PDT
Comment on attachment 156786 [details]
Should fix SVG, but may have other bugs

Attachment 156786 [details] did not pass chromium-ews (chromium-xvfb):
Output: http://queues.webkit.org/results/13452100

New failing tests:
svg/custom/use-detach.svg
Comment 7 WebKit Review Bot 2012-08-06 19:48:33 PDT
Created attachment 156841 [details]
Archive of layout-test-results from gce-cr-linux-07

The attached test failures were seen while running run-webkit-tests on the chromium-ews.
Bot: gce-cr-linux-07  Port: <class 'webkitpy.common.config.ports.ChromiumXVFBPort'>  Platform: Linux-2.6.39-gcg-201203291735-x86_64-with-Ubuntu-10.04-lucid
Comment 8 Eric Seidel (no email) 2012-08-06 21:24:02 PDT
Perfect!  That one appears to be a progression.  I'll upload a patch for real review shortly.
Comment 9 Eric Seidel (no email) 2012-08-06 23:53:22 PDT
Created attachment 156880 [details]
Patch
Comment 10 WebKit Review Bot 2012-08-07 03:29:52 PDT
Comment on attachment 156880 [details]
Patch

Attachment 156880 [details] did not pass chromium-ews (chromium-xvfb):
Output: http://queues.webkit.org/results/13452225

New failing tests:
svg/custom/use-detach.svg
Comment 11 WebKit Review Bot 2012-08-07 03:29:56 PDT
Created attachment 156905 [details]
Archive of layout-test-results from gce-cr-linux-03

The attached test failures were seen while running run-webkit-tests on the chromium-ews.
Bot: gce-cr-linux-03  Port: <class 'webkitpy.common.config.ports.ChromiumXVFBPort'>  Platform: Linux-2.6.39-gcg-201203291735-x86_64-with-Ubuntu-10.04-lucid
Comment 12 Eric Seidel (no email) 2012-08-07 12:38:56 PDT
Created attachment 156976 [details]
Patch including more updated pixel results
Comment 13 Eric Seidel (no email) 2012-08-08 12:52:39 PDT
Any thoughts?
Comment 14 Eric Seidel (no email) 2012-08-09 00:26:51 PDT
Comment on attachment 156976 [details]
Patch including more updated pixel results

Thanks mitz!
Comment 15 WebKit Review Bot 2012-08-09 00:59:06 PDT
Comment on attachment 156976 [details]
Patch including more updated pixel results

Clearing flags on attachment: 156976

Committed r125160: <http://trac.webkit.org/changeset/125160>
Comment 16 WebKit Review Bot 2012-08-09 00:59:11 PDT
All reviewed patches have been landed.  Closing bug.