Open Bug 1158562 Opened 9 years ago Updated 2 years ago

Rotating image with transform-style: preserve-3d doesn't repaint properly

Categories

(Core :: Layout, defect)

40 Branch
defect

Tracking

()

Tracking Status
firefox40 --- affected

People

(Reporter: MatsPalmgren_bugz, Unassigned)

References

()

Details

Attachments

(2 files, 4 obsolete files)

STR
1. load http://fff.cmiscm.com/#!/section/universe
2. wait for it load and for the intro animation to stop
3. press the mouse button somewhere in the center of the
   page and drag slowly to the left, then release the mouse

ACTUAL RESULT
The background to the right of the image isn't repainted properly
leaving fragments of the image behind.  There is also some weird
"singularity effect" going on.

Also, this page works differently in Chrome.  I don't know which
is correct although I guess the rendering in Chrome is what the
author intended.

Nightly 40.0a1 (2015-04-15) on Linux64
Attached image screenshot on windows7
On windows7, is this same bug? 

STR
1. open the url

Pushlog:
https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=2a61df4eaa2d&tochange=24ba8274ed60

Last good: 2a61df4eaa2d
First bad: 823227372483
Attached image screenshot on Linux
Here's what it looks like on Linux.  Some areas are not repainted
to the right, and a weird error in the center of the image.
For the Linux case, it may be due to issues in Skia transforming elements behind the camera.  Perhaps the fix added to Bug 1072898 could correct it.
Depends on: 1157984
Set dependency on incorrect bug, reverting.
No longer depends on: 1157984
I have reproduced the result shown in the Linux screenshot on OSX by setting the layers.acceleration.disabled preference to false.  I have confirmed that the fix added to Bug 1072898 corrects it visually; however, there are also some assertions that the fix from Bug 1072898 did not correct:

[GFX3-]: Surface width or height <= 0!
[GFX3-]: Surface width or height <= 0!
Crash Annotation GraphicsCriticalError: |[0][GFX1-]: Failed to allocate a surface due to invalid size Size(0,0)[GFX1-]: Failed to allocate a surface due to invalid size Size(0,0)
Assertion failure: aData, at /Users/kgilbert/dev/mozilla-central/gfx/2d/Factory.cpp:822
The extremely stretched textures and inverted geometry has been fixed with the patch in Bug 1072898; however, there appears to still be some culling issues on the example site linked in this bug.  These culling issues have recently regressed, with the same effects in the OpenGL compositor as well.

While digging further, I have noticed that Matrix4x4::TransformBounds is not handling the case when layers are both in front and behind the w=0 plane.  A similar fix to what was applied for Matrix4x4::ProjectRectBounds may be necessary here.  I am attempting to determine if the remaining effect of the regression is related to this.
Assignee: nobody → kgilbert
Whiteboard: [webvr]
Blocks: 1186575
Whiteboard: [webvr] → [webvr][vrm2]
Bug 1158562 - Part 1: Extend gfx::2d classes to support both float and double precision
- Implemented templates for Coord, Point, Point3D, Point4D, Size, Margin
  and Rect to create double precision versions.
Attachment #8644711 - Flags: review?(vladimir)
Bug 1157984 - Part 2: Implement double precision clipping functions in Matrix4x4
- Implement Matrix4x4::TransformAndClipBounds
- Update methods in Matrix4x4 with templates, allowing for both single
  and double precision.
Attachment #8644712 - Flags: review?(vladimir)
Bug 1157984 - Part 3: Correct bounding box transformations to support projections and correct clipping when transforming behind the camera
- Update callsites of Matrix4x4::TransformBounds to use
  Matrix4x4::TransformAndClipBounds.
Attachment #8644713 - Flags: review?(vladimir)
Bug 1157984 - Part 4: Remove gfxRect::TransformBounds
Attachment #8644714 - Flags: review?(vladimir)
Attachment #8644711 - Attachment is obsolete: true
Attachment #8644711 - Flags: review?(vladimir)
Attachment #8644712 - Attachment is obsolete: true
Attachment #8644712 - Flags: review?(vladimir)
Attachment #8644713 - Attachment is obsolete: true
Attachment #8644713 - Flags: review?(vladimir)
Attachment #8644714 - Attachment is obsolete: true
Attachment #8644714 - Flags: review?(vladimir)
(In reply to :kip (Kearwood Gilbert) from comment #7)
> Created attachment 8644711 [details]
> MozReview Request: Bug 1158562 - Part 1: Extend gfx::2d classes to support
> both float and double precision
> 
> Bug 1158562 - Part 1: Extend gfx::2d classes to support both float and
> double precision
> - Implemented templates for Coord, Point, Point3D, Point4D, Size, Margin
>   and Rect to create double precision versions.

So, I hate "DblPoint" "DblRect" etc.  "PointD" and "RectD" seem much better and cleaner.  I realize it's a bit bikeshedding, but it's also a pretty core naming decision.  Also not a huge fan of using "F" as the float type template parameter.. actually calling it "FloatType" or something would be cleaner when it's used.

Also note that you set default of "typename F = float", whereas before it was actually "Float" (gfx::Float) which is defined in Types.h.  You should keep it as Float, and possibly ad gfx::Double as well.

You'll want to get r+ on this from probably both bas and jrmuizel, given the core Moz2D change.
Flags: needinfo?(jmuizelaar)
Flags: needinfo?(bas)
Ugh, wrong bug.
Flags: needinfo?(jmuizelaar)
Flags: needinfo?(bas)
Summary: Rotating image with transform-style: preserve-3d doesn't repaint properly → [webvr] Rotating image with transform-style: preserve-3d doesn't repaint properly
(WebVR is no longer dependent on this issue, updated tags)

I suspect that this may have been solved by Miko's recent BSP implementation for plane splitting.  Could you confirm Miko?
Flags: needinfo?(mikokm)
Whiteboard: [webvr][vrm2]
Summary: [webvr] Rotating image with transform-style: preserve-3d doesn't repaint properly → Rotating image with transform-style: preserve-3d doesn't repaint properly
(In reply to :kip (Kearwood Gilbert) from comment #13)
> (WebVR is no longer dependent on this issue, updated tags)
> 
> I suspect that this may have been solved by Miko's recent BSP implementation
> for plane splitting.  Could you confirm Miko?

I am not able to reproduce this with HW acceleration enabled Nightly on Windows or OSX. However, the bug is still present if the pref layers.acceleration.disabled is set to true. This seems like a problem with BasicCompositor backend or Skia.

Similar texturing issues can be seen with the site http://www.keithclark.co.uk/labs/css-fps/nojs/.
Flags: needinfo?(mikokm)

The bug assignee didn't login in Bugzilla in the last 7 months, so the assignee is being reset.

Assignee: kearwood → nobody
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: