RESOLVED FIXED 58587
chromium gpu draws scrollbars slightly differently in debug vs. release modes on
https://bugs.webkit.org/show_bug.cgi?id=58587
Summary chromium gpu draws scrollbars slightly differently in debug vs. release modes on
Dirk Pranke
Reported 2011-04-14 15:40:01 PDT
chromium gpu draws scrollbars slightly differently in debug vs. release modes: DEBUG GPU LINUX : compositing/geometry/horizontal-scroll-composited.html = IMAGE DEBUG GPU LINUX : fast/canvas/image-object-in-canvas.html = IMAGE DEBUG GPU LINUX : media/video-zoom.html = IMAGE DEBUG GPU LINUX : platform/chromium/compositing/layout-width-change.html = IMAGE It's unclear if this is also a 32/64 thing.
Attachments
Patch (736.01 KB, patch)
2012-02-10 16:03 PST, Ami Fischman
no flags
Patch (875.89 KB, patch)
2012-02-13 10:32 PST, Ami Fischman
no flags
James Robinson
Comment 1 2011-04-27 15:09:08 PDT
*** Bug 59639 has been marked as a duplicate of this bug. ***
Kenneth Russell
Comment 2 2011-04-27 15:19:27 PDT
\
Andrew Scherkus
Comment 3 2011-05-19 18:33:52 PDT
Summarizing some internal discussion: We don't think it's due to floating point differences between debug/release since we set -mfpmath=sse -msse2 http://src.chromium.org/viewvc/chrome/trunk/src/build/common.gypi?&view=markup I tried 32-bit Debug build of DRT and got the same pixel differences. Looks like this is a pure Debug vs Release issue not a 32-bit vs 64-bit issue.
James Robinson
Comment 4 2011-05-19 18:40:12 PDT
Could you try building in debug the release mode optimization flags to see if that's the issue? The other question is what component/library is changing behavior - we rely on some native theme code to actually draw the scrollbar parts, so it's possible that this code is behaving differently. I don't know at what point we call into linux specific libraries but presumably we could try replacing just the libraries in question with release versions to see what happens.
Ami Fischman
Comment 5 2012-02-10 16:02:04 PST
The scroll-bar-related problems described in this bug appear to have been resolved (jamesr's recently-announced change?). The last remaining mention of BUGWK58587 in test_expectations.txt is for media/video-controls-rendering.html, which appears to not be debug/release-related at all and is a simple rebaseline, which I will upload in a bit. Once that lands I think this bug can be closed.
Ami Fischman
Comment 6 2012-02-10 16:03:25 PST
WebKit Review Bot
Comment 7 2012-02-10 16:43:24 PST
Comment on attachment 126598 [details] Patch Attachment 126598 [details] did not pass chromium-ews (chromium-xvfb): Output: http://queues.webkit.org/results/11447900 New failing tests: media/video-controls-rendering.html
Ami Fischman
Comment 8 2012-02-13 10:32:15 PST
WebKit Review Bot
Comment 9 2012-02-13 11:23:21 PST
Comment on attachment 126791 [details] Patch Rejecting attachment 126791 [details] from commit-queue. fischman@chromium.org does not have committer permissions according to http://trac.webkit.org/browser/trunk/Tools/Scripts/webkitpy/common/config/committers.py. - If you do not have committer rights please read http://webkit.org/coding/contributing.html for instructions on how to use bugzilla flags. - If you have committer rights please correct the error in Tools/Scripts/webkitpy/common/config/committers.py by adding yourself to the file (no review needed). The commit-queue restarts itself every 2 hours. After restart the commit-queue will correctly respect your committer rights.
Ami Fischman
Comment 10 2012-02-13 13:34:34 PST
Comment on attachment 126791 [details] Patch Clearing flags on attachment: 126791 Committed r107600: <http://trac.webkit.org/changeset/107600>
Ami Fischman
Comment 11 2012-02-13 13:34:40 PST
All reviewed patches have been landed. Closing bug.
Note You need to log in before you can comment on or make changes to this bug.