871729 - Changing opacity of SVG path causes image/pixel shifting

Status: RESOLVED FIXED

(Core :: Graphics, defect)

Description

[Ben Aiken]

Attachment: FF_Path Issue.zip

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_8_2) AppleWebKit/537.31 (KHTML, like Gecko) Chrome/26.0.1410.65 Safari/537.31

Steps to reproduce:

Hovered paths in an SVG that cause opacity changes to those zones.


Actual results:

Paths have blurring/pixel shifting as does underlying image embedded within SVG.


Expected results:

No blurring/pixel shifting should occur.

Comment 1

[Ben Aiken]

Results from mozregression tool:

Last good nightly: 2013-04-15
First bad nightly: 2013-04-16

Pushlog:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=261d6997d1d1&tochange=1d9c510b3742

Comment 2

[Ben Aiken]

Unable to reproduce in latest Windows nightly but reproduced on OSX on multiple computers.

Comment 3

[Loic]

(In reply to Ben Aiken from comment #1)
> Results from mozregression tool:
> 
> Last good nightly: 2013-04-15
> First bad nightly: 2013-04-16
> 
> Pushlog:
> http://hg.mozilla.org/mozilla-central/
> pushloghtml?fromchange=261d6997d1d1&tochange=1d9c510b3742

It could be this suspected bug:
Matt Woodrow — Bug 861042 - Manually invalidate frames with both opacity and svg effects, as this isn't caught by DLBI. r=roc

Comment 4

[Ben Aiken]

Any progress on whether Bug 861042 has anything to do with this issue?

Comment 5

[Matt Woodrow (:mattwoodrow)]

It's not obvious that this would be caused by bug 861042. That patch only added an invalidation, which shouldn't ever cause incorrect painting. At worst it should only cause unnecessary repainting.

Comment 6

[Ben Aiken]

Just out of curiosity, is the 'regressionwindow-wanted' keyword an action item for our side, or is that for your team?

Comment 7

[Ben Aiken]

Also, I tried doing some bisecting through mozregression to help narrow this one down, but am seeing the following:

do you want to bisect further by fetching the repository and building? (y or n) y
Building changesets:
Trunk not found.
Removed old mozbuild-trunk directory. Downloading a fresh repo from mozilla-central...
requesting all changes
adding changesets
adding manifests
transaction abort!
rollback completed
abort: Connection reset by peer

It's been happening consistently over multiple days - any tips or known ways to get around this?

Comment 8

[Alice0775 White]

I can reproduce the problem in Windows7 Aurora23.0a2.

Regression window(m-i):
Good:
http://hg.mozilla.org/integration/mozilla-inbound/rev/deab88ac216a
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:23.0) Gecko/20130415 Firefox/23.0 ID:20130415052104
Bad:
http://hg.mozilla.org/integration/mozilla-inbound/rev/644f16c3f87c
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:23.0) Gecko/20130415 Firefox/23.0 ID:20130415053103
Pushlog;
http://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=deab88ac216a&tochange=644f16c3f87c

Regressed by: 
644f16c3f87c	Jonathan Watt — Bug 861805 - Stop layers from snapping transforms for SVG content. r=roc



(PS. And I also found an another problem, Bug 871917)

Comment 9

[Ben Aiken]

Any status update on this one? This one is crucial for us as is the linked Bug 871917. We really appreciate any efforts to make sure this issue is fixed before going out in a release.

Comment 10

[Robert O'Callahan (:roc) (email my personal email if necessary)]

jwatt is on vacation. This seems like a regression we should fix.

Comment 11

[Matt Woodrow (:mattwoodrow)]

When you hover over the elements that change opacity, we change that element to being an active layer (and also create other new layers because of the ordering).

Bug 861805 changed us to *not* snap these layers to pixel boundaries, so they get composited at a sub-pixel position and end up blurry.

Around 100ms later we hit the timeout period, and shift back to the flattened (non-blurry) state.

Bug 861805 doesn't really go into much detail *why* we want this behaviour for SVG, but I'm guessing we only want it in some cases.

We might be better backing it out until jwatt is back.

Comment 12

[Robert O'Callahan (:roc) (email my personal email if necessary)]

That sounds like a good idea.

Comment 13

[Matt Woodrow (:mattwoodrow)]

https://tbpl.mozilla.org/?tree=Try&rev=ad2dae7f54fc

Comment 14

[Matt Woodrow (:mattwoodrow)]

Backed out bug 861805 as https://hg.mozilla.org/integration/mozilla-inbound/rev/854310083421