chromium gpu draws scrollbars slightly differently in debug vs. release modes on

• Component: Layout and Rendering
• Status: RESOLVED FIXED

[Dirk Pranke]

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.

[James Robinson]

*** Bug 59639 has been marked as a duplicate of this bug. ***

[Kenneth Russell]

\

[Andrew Scherkus]

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]

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]

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]

Created attachment 126598 [details]
Patch

[WebKit Review Bot]

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]

Created attachment 126791 [details]
Patch

[WebKit Review Bot]

Comment on attachment 126791 [details]
Patch

Rejecting attachment 126791 [details] from commit-queue.

[e-mail] 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 on attachment 126791 [details]
Patch

Clearing flags on attachment: 126791

Committed r107600: <http://trac.webkit.org/changeset/107600>

[Ami Fischman]

All reviewed patches have been landed.  Closing bug.