Closed Bug 622585 Opened 14 years ago Closed 13 years ago

CSS3 transforms + hardware acceleration: Transformed elements that are partially clipped are painted incorrectly

Categories

(Core :: Graphics, defect)

Product:
Core
Component:
Graphics
Platform:
x86
macOS
Type:
defect
Priority:
Not set
Severity:
major

Tracking

()

Status:
RESOLVED FIXED
Tracking Flags:
Tracking Status
blocking2.0 --- betaN+

People

(Reporter: thecoreh, Assigned: mattwoodrow)

References

Details

(Keywords: regression, Whiteboard: [softblocker][final?])

Attachments

(6 files, 1 obsolete file)

test case
460 bytes, text/html
Details
Screenshot of the rendering problems BEFORE the regression (not a screenshot of the current bug)
57.53 KB, image/png
Details
Reftest that catches this
2.43 KB, patch
roc
: review+
Details | Diff | Splinter Review
Part 2: Disable wrapping for FBOs
1.35 KB, patch
jrmuizel
: review+
Details | Diff | Splinter Review
Part 3: Change D3D10 to use clamp instead of wrap.
3.67 KB, patch
bas.schouten
: review+
Details | Diff | Splinter Review
New flipping logic v2
4.55 KB, patch
mattwoodrow
: review+
Details | Diff | Splinter Review 
User-Agent:       Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:2.0b8) Gecko/20100101 Firefox/4.0b8
Build Identifier: 4.0b8

If you use JavaScript and CSS3 to transform an HTML element that is partially clipped by its parent element (i.e. partially outside the parent element bounds, and the parent element is either <body> or has style="overflow: hidden") the rendering is incorrect.

This only seems to happen via frequent style changes made via JavaScript with a timer. Transforms already present on page load don't seem to be affected.

Slowing down the JS timers seems to reduce the effects of the bug. Maybe it's related to some sort of lengthy software operation (Painting the div?) not catching up with the faster hardware rendering? I'm not sure, this is just some wild speculation.

Reproducible: Always

Steps to Reproduce:
1. Make sure Hardware Acceleration is turned on
2. Open the test case attached
Actual Results:  
The transformed div is only rendered partially:

 +------------ . . .
 |      /\
 |     /*/
 |    /*/
 |   /*/
 |  /*/
 | /*/
 |/*/
 |\/
 |
 .
 .
 .

Expected Results:  
The transformed div should be rendered completely.

 +------+----- . . .
 |*******\
 |*******/
 |******/
 |*****/
 |****/
 |***/
 +**/
 |\/
 |
 .
 .
 .

I'm running Snow Leopard on a late 2008 MacBook White, with an Intel GMA X3100.
Attached file test case — 
Test with both hardware acceration on and off to see the difference.
Per the described results in comment 0 WFM using Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b9pre) Gecko/20110103 Firefox/4.0b9pre ID:20110103030359 and hardware acceleration on, using a D3D9 layers card and D2D disabled.

However, I get a seemingly different issue, whereby the red square of the testcase overwrites the bookmarks toolbar and tab bar.

Before I break this out into it's own bug/have a route around for dupes, can you see if your issue has the same regression range as mine please.

For my issue: Last good nightly: 2010-10-21 ; First bad nightly: 2010-10-22

https://wiki.mozilla.org/QA/Triage#How_to_Help_with_Regressions_--_Finding_Regression_Windows
Component: Layout: View Rendering → Graphics
QA Contact: layout.view-rendering → thebes
blocking2.0: --- → ?
(In reply to comment #2)
> Per the described results in comment 0 WFM using Mozilla/5.0 (Windows NT 6.1;
> WOW64; rv:2.0b9pre) Gecko/20110103 Firefox/4.0b9pre ID:20110103030359 and
> hardware acceleration on, using a D3D9 layers card and D2D disabled.
> 
> However, I get a seemingly different issue, whereby the red square of the
> testcase overwrites the bookmarks toolbar and tab bar.
> 
> Before I break this out into it's own bug/have a route around for dupes, can
> you see if your issue has the same regression range as mine please.
> 
> For my issue: Last good nightly: 2010-10-21 ; First bad nightly: 2010-10-22
> 
> https://wiki.mozilla.org/QA/Triage#How_to_Help_with_Regressions_--_Finding_Regression_Windows

Hey Ed,

I'm sorry, I'm not completely familiar with the nightly builds directory structure. I found those builds for 2010-10-21:

	2010-10-21-03-mozilla-1.9.1/
	2010-10-21-03-mozilla-1.9.2-debug/
	2010-10-21-03-mozilla-1.9.2/
	2010-10-21-03-mozilla-central-debug/
	2010-10-21-03-mozilla-central/
	2010-10-21-03-tracemonkey/
	2010-10-21-04-electrolysis/
	2010-10-21-04-mozilla-1.9.2/
	2010-10-21-04-mozilla-central/
	2010-10-21-05-tracemonkey/

Which of them should I download to test the regression?

Thanks.
You want the builds ending in just mozilla-central. Of those, the "-03"/"-04" appended to the date just means hour of creation - depending on OS required and variation day in day out, the build you want can be in any of the hourly folders (depending on when it actually finished building).

In your case for OS X...

21st: http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2010/10/2010-10-21-03-mozilla-central/firefox-4.0b8pre.en-US.mac64.dmg

22nd: http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2010/10/2010-10-22-03-mozilla-central/firefox-4.0b8pre.en-US.mac64.dmg

Thanks :-)
Hey Ed, I've tested the two nightlies you've linked. The regression didn't happen between october 21st and 22nd.

However, I was able to isolate the regression date:

Working: 2010-11-15 - Broken: 2010-11-16

However, on the 2010-11-15 ("working") build, the rendering isn't perfect either. There are some small rendering artifacts. I'll attach a screenshot.
Keywords: regression
(Sorry for double posting) I also made a video of the bug happening, for those with different hardware configurations: http://www.youtube.com/watch?v=PPQ4qO-wg5U
Great work Marco and thanks for the video - makes this really clear. My issue indeed appears to be different, will log separately.

Marking as confirmed based on video. 

I don't suppose you could post the specific revision IDs from the two builds you mention for your regression range? It's just that the date isn't as precise as knowing the exact rev. The revision info can be found under about:buildconfig when each build is running - thanks!
Status: UNCONFIRMED → NEW
Ever confirmed: true
Version: unspecified → Trunk
Here they are:

2010-11-15 - http://hg.mozilla.org/mozilla-central/rev/edf41ff32f08
2010-11-16 - http://hg.mozilla.org/mozilla-central/rev/a42e9b001bc8

Nice to see you guys switched to mercurial. It's pretty neat.
Thanks!

Main regression range pushlog: 
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=edf41ff32f08&tochange=a42e9b001bc8

Couple of things stand out at first glance: Bug 593342 and bug 612171, but someone else who knows what they're doing please take a more thorough look! (Also note comment 5 about minor symptoms existing before this main regression range too). CCing Joe since assignee of one of those patches.
That looks *exactly* like something we had to fix in the past. I can reproduce it on my computer too. It's probably something we regressed when we were fixing all those clipping issues on transformed framebuffers, Matt.

Can you take a look at it?
Assignee: nobody → matt.woodrow+bugzilla
blocking2.0: ? → betaN+
Whiteboard: [soft blocker]
Whiteboard: [soft blocker] → [softblocker]
Looks like our flipping of the scissor rect logic is *still* wrong.

Finally adding a test so we don't hit this again. Quite hard to catch since only ColorLayer's get this clipping applied, yet we need a CanvasLayer to keep the container active.
Attached patch New flipping logic (obsolete) — — Splinter Review 
This fixes the reported problem for me.

This is all getting rather horrible. We should try abstract the flipping logic inside the GLContext (or LayerManagerOGL) and then share clipping logic with the other layer managers so we don't have so much repeated code.

Probably something best to do after 4.0 though.

This still doesn't make the test pass sadly, we need a fix for 630835 and there is still a red fringe on the edge of the drawn container. I guess this has something to do with wrapping of the texture, will see if I can figure it out.
Attachment #510080 - Flags: review?(joe)
Depends on: 630835
Test passes now! (with my incorrect hack fix for 630835).

We may need to check the other accelerated backends for this problem too.
Attachment #510084 - Flags: review?(joe)
Attachment #510071 - Flags: review?(roc)
Looks like D3D9 is already doing this.
Attachment #510783 - Flags: review?(bas.schouten)
Attachment #510080 - Flags: review?(joe) → review?(jmuizelaar)
Attachment #510084 - Flags: review?(joe) → review?(jmuizelaar)
Is there a good reason that this blocks betaN?  If not, it should be moved over to final+.
Whiteboard: [softblocker] → [softblocker][final?]
Attachment #510084 - Flags: review?(jmuizelaar) → review+
Comment on attachment 510080 [details] [diff] [review]
New flipping logic


>   }
> 
>   /**
>    * Setup the viewport and projection matrix for rendering
>    * to a window of the given dimensions.
>    */
>   void SetupPipeline(int aWidth, int aHeight);
> 
>+  /**
>+   * Returns true if all drawing is done with a Y axis flip
>+   */
>+  bool IsDrawingFlipped() {

Maybe add a comment about why this implies flipped drawing.
Attachment #510080 - Flags: review?(jmuizelaar) → review+
I think this should be final+... this makes pretty much every example of transforms I've seen recently draw garbage all over my viewport, since they all end up extending outside the viewport a bit.
Attachment #510783 - Flags: review?(bas.schouten) → review+
Added better comment for IsDrawingFlipped.

Carrying forward r=jrmuizel.
Attachment #510080 - Attachment is obsolete: true
Attachment #512694 - Flags: review+
Test passes now on try.

Landed it as http://hg.mozilla.org/mozilla-central/rev/1da3405c74fd
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: