Changing opacity of SVG path causes image/pixel shifting

RESOLVED FIXED

Status

()

defect
RESOLVED FIXED
6 years ago
5 years ago

People

(Reporter: ben.aiken, Assigned: mattwoodrow)

Tracking

(Blocks 1 bug, {regression})

23 Branch
x86
All
Points:
---

Firefox Tracking Flags

(firefox22 unaffected, firefox23 ?, firefox24 ?)

Details

Attachments

(1 attachment)

327.67 KB, application/octet-stream
Details
(Reporter)

Description

6 years ago
Posted file 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.
(Reporter)

Comment 1

6 years ago
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
(Reporter)

Comment 2

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

Updated

6 years ago
Keywords: regression
Version: Other Branch → 23 Branch

Comment 3

6 years ago
(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

Updated

6 years ago
(Reporter)

Comment 4

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

Updated

6 years ago
Flags: needinfo?(matt.woodrow)
(Assignee)

Comment 5

6 years ago
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.
Flags: needinfo?(matt.woodrow)

Updated

6 years ago
(Reporter)

Comment 6

6 years ago
Just out of curiosity, is the 'regressionwindow-wanted' keyword an action item for our side, or is that for your team?
(Reporter)

Comment 7

6 years ago
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

6 years ago
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)
Blocks: 861805
OS: Mac OS X → All

Updated

6 years ago
Status: UNCONFIRMED → NEW
Ever confirmed: true
(Reporter)

Comment 9

6 years ago
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.
jwatt is on vacation. This seems like a regression we should fix.
Assignee: nobody → matt.woodrow
(Assignee)

Comment 11

6 years ago
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.
Flags: needinfo?(roc)
That sounds like a good idea.
Flags: needinfo?(roc)
(Assignee)

Updated

6 years ago
Status: NEW → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.