Bug 86026

Summary: [Qt][32 bit] Child div overlay on parent div results in image diff when it shouldn't
Product: WebKit Reporter: Dave Tharp <dtharp>
Component: CSSAssignee: Nobody <webkit-unassigned>
Severity: Normal CC: allan.jensen, ossy
Priority: P2 Keywords: Qt, QtTriaged
Version: 528+ (Nightly build)   
Hardware: Unspecified   
OS: Linux   
Bug Depends on:    
Bug Blocks: 87008    
Description Flags
ref test for testcase
actual output (png)
expected output (png)
diff output (png)
diff output png from "compare -verbose -identify" none

Description Dave Tharp 2012-05-09 15:38:42 PDT
Attached are two html files: div-overlay.html and div-overlay-expected.html (reference test).

When div-overlay.html is run in new-run-webkit-tests, it's output is pixel compared to the output from div-overlay-expected.html (presuming they are both in the same directory).

The design of the test is simple.  A parent div is created 300px wide by 100px tall with a red background.  A child div is created 300px wide by 100px tall with a green background. The rendered image should be a 300x100 green rectangle.  

The reference test is the same except the parent div has a *green* background. The rendered image should be the same as the test html: a 300x100 green rectangle.

On all ports except QT Linux 32-bit, this test will pass. 

The failure on QT Linux 32-bit is strange:
1. Visually, there is no difference detectable.
2. The output pngs' checksums are different, and the file sizes are off by 3 bytes.
3. Looking at the output pngs in gimp, I am able to inspect the green pixels. Both pngs' "green" are #008000
4. The diff png generated is simply a large completely black square, which I believe means no diffs (I verified by changing text and observing that the changed text appears white inside the black square).
5. Note that if the reference test is changed such that the parent div has a red background, the test passes. This would seem to indicate that somehow the red background is visible when Qt 32-bit renders, but close inspection of the resultant pngs does not confirm this.

Attaching the pngs as well.
Comment 1 Dave Tharp 2012-05-09 15:39:31 PDT
Created attachment 141030 [details]
Comment 2 Dave Tharp 2012-05-09 15:40:01 PDT
Created attachment 141031 [details]
ref test for testcase
Comment 3 Dave Tharp 2012-05-09 15:40:55 PDT
Created attachment 141032 [details]
actual output (png)
Comment 4 Dave Tharp 2012-05-09 15:41:33 PDT
Created attachment 141033 [details]
expected output (png)
Comment 5 Dave Tharp 2012-05-09 15:42:07 PDT
Created attachment 141034 [details]
diff output (png)
Comment 6 Dave Tharp 2012-05-10 09:28:12 PDT
More research on this issue:

I have analyzed the actual vs expected output with "compare -verbose -identify". The interesting part is the histogram and the resultant diff.png.

The relevant part of the histograms:

== actual ==
       296: (  0,  0,  0,255) #000000 black
     29700: (  0,128,  0,255) #008000 green
         4: (  1,  1,  1,255) #010101 rgba(1,1,1,1)
       300: (  1,127,  0,255) #017F00 rgba(1,127,0,1)
         1: (  2,  2,  2,255) #020202 rgba(2,2,2,1)

== expected == 
       296: (  0,  0,  0,255) #000000 black
     30000: (  0,128,  0,255) #008000 green
         4: (  1,  1,  1,255) #010101 rgba(1,1,1,1)
         1: (  2,  2,  2,255) #020202 rgba(2,2,2,1)

Note that expected has 30,000 green pixels as expected (300 * 100). Now the actual has only 29700 green pixels. There are 300 missing, as if the child div is missing an entire line. Where are these 300 pixels? Well, there are 300 pixels that are *almost* green (1,127,0) present. This line of pixels is off by 1 bit in red and green.  The diff png (attached) shows this line as the very bottom line of the rectangle.
Comment 7 Dave Tharp 2012-05-10 09:29:19 PDT
Created attachment 141183 [details]
diff output png from "compare -verbose -identify"
Comment 8 Csaba Osztrogon√°c 2012-05-14 06:12:45 PDT
A similar bug: https://bugs.webkit.org/show_bug.cgi?id=86130
Comment 9 Jocelyn Turcotte 2014-02-03 03:20:48 PST
=== Bulk closing of Qt bugs ===

If you believe that this bug report is still relevant for a non-Qt port of webkit.org, please re-open it and remove [Qt] from the summary.

If you believe that this is still an important QtWebKit bug, please fill a new report at https://bugreports.qt-project.org and add a link to this issue. See http://qt-project.org/wiki/ReportingBugsInQt for additional guidelines.