flickering with clipPath

RESOLVED WORKSFORME

Status

()

Core
Graphics
--
major
RESOLVED WORKSFORME
7 years ago
6 years ago

People

(Reporter: Jeremie, Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(2 attachments, 2 obsolete attachments)

(Reporter)

Description

7 years ago
User-Agent:       Mozilla/5.0 (Windows; Windows NT 5.1; en-US; rv:2.0b2pre) Gecko/20100707 Minefield/4.0b2pre
Build Identifier: Mozilla/5.0 (Windows; Windows NT 5.1; en-US; rv:2.0b2pre) Gecko/20100707 Minefield/4.0b2pre

Here is a tricking regression. The link I provide is a work in progress (I freezed it at that URL for the purpose of this bug) where I try to show the interests of inline SVG inside an HTML document.

For a few days now (at least 2 or 3), I experience some random flickering on the objects which use a clipPath. The flickering disappear if I applies some filters to those objects.

I say it's a regression (therefor I thing it's a major bug) because if I try to use FF 3.6 with the HTML5 Parser enable, it work fine without any flickering.

Reproducible: Always

Steps to Reproduce:
1. open the provide URL
2. set a Puzzle (let the default options)
3. try to move some pieces over other pieces
 
Actual Results:  
Some pieces are rectangular where they have to be clipped and when you move the piece they sometime do not render properly.

Expected Results:  
The pieces should be cleanly clipped and should not flicker while moving whatever you applies filters or not.

Comment 1

7 years ago
Can you produce a minimised testcase and attach it to the bug please. The example given is too large to figure out what's going on.
Alternately, can you narrow down when the problem appeared using nightlies?

For what it's worth, I see no flickering on Mac...
(Reporter)

Comment 3

7 years ago
Created attachment 456461 [details]
Reduce testcase

Ok, here is a shorten test case.

Move your mouse over, in and out the red SVG elements. They flick but they should not.

This is a real subtle problem because if you change something in the HTML or in the CSS, the problem vanished.

the combination of the CSS properties font-family, position and vertical align is require (remove one of them and there is no problem any more).
The use of canvas is require has well (if you use an img tag instead of the canvas tag, no problem).
I'm not seeing any red elements in that testcase...
(Reporter)

Comment 5

7 years ago
(In reply to comment #2)
> Alternately, can you narrow down when the problem appeared using nightlies?

I'm working on it

> For what it's worth, I see no flickering on Mac...

I don't have a Mac so I can't test with it. I continue to dig on it but at that
time this bug occur on Windows and on Linux as well.

(In reply to comment #4)

Ah... I see, this is due to the lack of load event on the Image. The canvas is painted before the Image is rendered if the image is not in your browser cache. I'll fix the test case ASAP.
FWIW, no flicker for me on a Linux trunk build. (had to save the file locally to get the red puzzle-pieces to show up, too.)
Mozilla/5.0 (X11; Linux i686; en-US; rv:2.0b2pre) Gecko/20100708 Minefield/4.0b2pre
OS: All → Windows Vista
(Reporter)

Comment 7

7 years ago
Created attachment 456480 [details]
Update testcase for linux

Here is an update version of the testcase.

This update fix the load img issue in the previous test case.

I've change the font-size property of the body element. The consequence is that now, this test case allow me to show the bug on my linux laptop with Mozilla/5.0 (X11; Linux x86_64; en-US; rv:2.0b2pre) Gecko/20100708 Minefield/4.0b2pre

But with this change, this new testcase do not show the bug on my WinXP machine (but it still occur with the old test case).
(Reporter)

Comment 8

7 years ago
Created attachment 456570 [details]
Universal and simpler test case

Du to the feed back, I've dig into my test case to make it simpler and try to figure out why it behave differently between OS.

First of all, I have reduced the number of SVG elements and the complexity of the clip path. By doing that, the flickering effect is gone but, now, it's easier to see that sometimes, the clipPath is not visually rendered. If the clip path is applied, you can see a red square clipped by a half circle. If it is not, you'll see a simple red square.

It seems that the problem is depending on the typographic size. So with this new test case, you can easily change the font size to check at which point the clipping rendering is messing up. This could explain why different OS behave differently: the typo are not the same and their own default size could be different.

For example, with my WINXP machine, the clip path is well rendered with the font size values : 24, 22, 19, 18, 16, 15, 8, 7, 5, 3 and 0 pixels. At other sizes, it is not rendered.
Attachment #456461 - Attachment is obsolete: true
Attachment #456480 - Attachment is obsolete: true

Comment 9

7 years ago
Here's some additional questions then if you're game...

Does it require canvas or can you simplify things such that it just uses an SVG image element?

Does it really require text with a font-size at the top or does anything that moves the svg down the page cause things to screw up?

If you convert this to xhtml so that it works on Firefox 3.6 does that still show a problem? Does that xhtml version show a problem on trunk?

Updated

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

Comment 10

7 years ago
(In reply to comment #9)

> Does it require canvas or can you simplify things such that it just uses an SVG
> image element?

No, canvas is require, if I use an SVG image or an HTML img element inside a foreignObject I can not reproduce the problem

> Does it really require text with a font-size at the top or does anything that
> moves the svg down the page cause things to screw up?

Yes it's require and a text before the element with the property position:relative is require as well. It's also require to have this text inside an inline element with the CSS property vertical-align:middle.

> If you convert this to xhtml so that it works on Firefox 3.6 does that still
> show a problem? Does that xhtml version show a problem on trunk?

I've run the following test with the last test case :

HTML version with FF 3.6.6 and the HTML5 parser enable : no problem
HTML version with FF 3.7a5pre : the clipPath is never apply
HTML version with the trunk : The problem as describe above

XHTML version with FF 3.6.6 and the HTML5 parser enable : no problem
XHTML version with FF 3.7a5pre : no problem
XHTML version with the trunk : The problem as describe above

the FF 3.7a5pre, it's the build : Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.3a5pre) Gecko/20100424 Minefield/3.7a5pre

I'm sorry but I don't know where to find other trunk build to investigate when things change between this old build and the current trunk build.
(Reporter)

Comment 11

7 years ago
Created attachment 456619 [details]
XHTML version of the testcase

Comment 12

7 years ago
You can find old trunk builds here: http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/   trunk is in the directories that end mozilla-central

If you can get down to the day a fix is massively more likely given that the testcase is still relatively complex.

Please type about:buildconfig into the location bar and tell us the built from data for the last working build and the first broken one so we can get an accurate range.
(Reporter)

Comment 13

7 years ago
Ok, I've found that the build that break the XHTML test case is between 2010/04/26 built from http://hg.mozilla.org/mozilla-central/rev/2968d19b0165 and
2010/04/27 built from http://hg.mozilla.org/mozilla-central/rev/29a6a85fab8e

There is also a change on the way the HTML testcase react between 2010 05 03 built from http://hg.mozilla.org/mozilla-central/rev/83c887dff0da and
2010 05 04 built from http://hg.mozilla.org/mozilla-central/rev/d6bb0f9e9519

Hope this will help.

Comment 14

7 years ago
The log for the first is http://hg.mozilla.org/mozilla-central/shortlog/41393 my guess would be bug 542605 or possibly bug 561827 

The second is http://hg.mozilla.org/mozilla-central/shortlog/41756 which includes bug 373864 which enables the html5 parser. Before that, inline svg only works in xhtml so that's expected.

Comment 15

7 years ago
bug 561827 must have been a commit typo. I don't know what the real bug number would be.

Comment 16

7 years ago
Since this requires canvas to show the bug and seems to be as a result of the bug 542605 cairo checkin I think core->graphics is a better home.
Component: SVG → Graphics
QA Contact: general → thebes
(Reporter)

Comment 17

6 years ago
This bug looks ok now.

I do not have the time to check each version of Gecko to see when this happen but it works now :D
Status: NEW → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → FIXED

Comment 18

6 years ago
We use fixed if we know why and WFM if not.
Resolution: FIXED → WORKSFORME
You need to log in before you can comment on or make changes to this bug.