RESOLVED INVALID Bug 86026
[Qt][32 bit] Child div overlay on parent div results in image diff when it shouldn't
https://bugs.webkit.org/show_bug.cgi?id=86026
Summary [Qt][32 bit] Child div overlay on parent div results in image diff when it sh...
Dave Tharp
Reported 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.
Attachments
testcase (682 bytes, text/html)
2012-05-09 15:39 PDT, Dave Tharp
no flags
ref test for testcase (684 bytes, text/html)
2012-05-09 15:40 PDT, Dave Tharp
no flags
actual output (png) (6.04 KB, image/png)
2012-05-09 15:40 PDT, Dave Tharp
no flags
expected output (png) (6.04 KB, image/png)
2012-05-09 15:41 PDT, Dave Tharp
no flags
diff output (png) (3.22 KB, image/png)
2012-05-09 15:42 PDT, Dave Tharp
no flags
diff output png from "compare -verbose -identify" (5.90 KB, image/png)
2012-05-10 09:29 PDT, Dave Tharp
no flags
Dave Tharp
Comment 1 2012-05-09 15:39:31 PDT
Created attachment 141030 [details] testcase
Dave Tharp
Comment 2 2012-05-09 15:40:01 PDT
Created attachment 141031 [details] ref test for testcase
Dave Tharp
Comment 3 2012-05-09 15:40:55 PDT
Created attachment 141032 [details] actual output (png)
Dave Tharp
Comment 4 2012-05-09 15:41:33 PDT
Created attachment 141033 [details] expected output (png)
Dave Tharp
Comment 5 2012-05-09 15:42:07 PDT
Created attachment 141034 [details] diff output (png)
Dave Tharp
Comment 6 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 == Histogram: 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 == Histogram: 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.
Dave Tharp
Comment 7 2012-05-10 09:29:19 PDT
Created attachment 141183 [details] diff output png from "compare -verbose -identify"
Csaba Osztrogonác
Comment 8 2012-05-14 06:12:45 PDT
Jocelyn Turcotte
Comment 9 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.
Note You need to log in before you can comment on or make changes to this bug.