Re: [webkit-dev] Head-ups: massive TEXT rebaselining

2012-03-02 Thread Julien Chaffraix 
Hi everyone,

 I will land https://bugs.webkit.org/show_bug.cgi?id=75568 tomorrow to
 give enough time for people to react. This makes us lazily allocate
 layers when we get layout overflow. The upside is a good speed-up in
 painting / hit-testing and (likely) some memory improvement but it
 also means that 100+ tests will need a new baseline. I have tried to
 skip those I know about in the different platforms but I may have
 forgotten severals.

The patch did land yesterday but I reverted it due to one hidden bug.
This may confuse certain tools (I had an issue with garden-o-matic
picking up the TEXT failures due to the patch one day after) so beware
if you intent to rebaseline.

An updated patch was just attached on the bug and will be landed upon
review (hopefully next week). To avoid spamming webkit-dev further, I
will post the updates on the bug.

Thanks,
Julien
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

[webkit-dev] Head-ups: massive TEXT rebaselining

2012-02-29 Thread Julien Chaffraix 
Hi everyone,

TL;DR: If you don't maintain a bot or look at render tree dumps, I
guess this is not interesting to you.

I will land https://bugs.webkit.org/show_bug.cgi?id=75568 tomorrow to
give enough time for people to react. This makes us lazily allocate
layers when we get layout overflow. The upside is a good speed-up in
painting / hit-testing and (likely) some memory improvement but it
also means that 100+ tests will need a new baseline. I have tried to
skip those I know about in the different platforms but I may have
forgotten severals.

Here is the typical diff you should see:

--- 
/home/jchaffraix/Sources/WebKit/Source/WebKit/chromium/webkit/Debug/layout-test-results/fast/block/margin-collapse/103-expected.txt
+++ 
/home/jchaffraix/Sources/WebKit/Source/WebKit/chromium/webkit/Debug/layout-test-results/fast/block/margin-collapse/103-actual.txt
@@ -30,10 +30,12 @@
   RenderText {#text} at (0,1) size 68x18
 text run at (0,1) width 68: Your Name*
 RenderTextControl {INPUT} at (325,27) size 184x22
[bgcolor=#FF] [border: (2px inset #00)]
+  RenderBlock {DIV} at (2,3) size 180x16
 RenderBlock (floating) {SPAN} at (0,51) size 325x20 [color=#33]
   RenderText {#text} at (0,1) size 121x18
 text run at (0,1) width 121: Your e-mail address*
 RenderTextControl {INPUT} at (325,51) size 184x22
[bgcolor=#FF] [border: (2px inset #00)]
+  RenderBlock {DIV} at (2,3) size 180x16
 RenderBlock (floating) {SPAN} at (0,75) size 325x20 [color=#33]
   RenderText {#text} at (0,1) size 128x18
 text run at (0,1) width 128: Your degree program*
@@ -161,10 +163,6 @@
   RenderBlock {SPAN} at (0,16) size 600x20 [color=#33]
 RenderText {#text} at (245,1) size 110x18
   text run at (245,1) width 110: \x{A9}2003 Kevin Davis
-layer at (439,302) size 180x16
-  RenderBlock {DIV} at (2,3) size 180x16
-layer at (439,326) size 180x16
-  RenderBlock {DIV} at (2,3) size 180x16
 layer at (112,789) size 506x106 clip at (113,790) size 504x104
   RenderTextControl {TEXTAREA} at (0,517) size 506x106
[bgcolor=#FF] [border: (1px solid #00)]
 RenderBlock {DIV} at (3,3) size 500x16


The difference is only about layers being removed and RenderObject
being put back where they belong in the tree. There should be *no
change in the size of position of your RenderObject's* as they move.
Any change is a regression.

Feel free to pull me in on anything related to this rebaseline, I
would happily review or comment on any bug related.

Thanks,
Julien
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev