All users were logged out of Bugzilla on October 13th, 2018

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

NEW
Assigned to

Status

()

4 years ago
2 years ago

People

(Reporter: mats, Assigned: kip)

Tracking

40 Branch
Points:
---

Firefox Tracking Flags

(firefox40 affected)

Details

(URL)

Attachments

(2 attachments, 4 obsolete attachments)

(Reporter)

Description

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

Comment 1

4 years ago
Created attachment 8597664 [details]
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
(Reporter)

Comment 2

4 years ago
Created attachment 8597883 [details]
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.
(Assignee)

Comment 3

4 years ago
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.
(Assignee)

Updated

4 years ago
Depends on: 1157984
(Assignee)

Comment 4

4 years ago
Set dependency on incorrect bug, reverting.
No longer depends on: 1157984
(Assignee)

Comment 5

4 years ago
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
(Assignee)

Comment 6

4 years ago
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
(Assignee)

Updated

3 years ago
Whiteboard: [webvr]
(Assignee)

Updated

3 years ago
Blocks: 1186575

Updated

3 years ago
Whiteboard: [webvr] → [webvr][vrm2]
(Assignee)

Comment 7

3 years ago
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.
Attachment #8644711 - Flags: review?(vladimir)
(Assignee)

Comment 8

3 years ago
Created attachment 8644712 [details]
MozReview Request: Bug 1157984 - Part 2: Implement double precision clipping functions in Matrix4x4

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)
(Assignee)

Comment 9

3 years ago
Created attachment 8644713 [details]
MozReview Request: Bug 1157984 - Part 3: Correct bounding box transformations to support projections and correct clipping when transforming behind the camera

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)
(Assignee)

Comment 10

3 years ago
Created attachment 8644714 [details]
MozReview Request: Bug 1157984 - Part 4: Remove gfxRect::TransformBounds

Bug 1157984 - Part 4: Remove gfxRect::TransformBounds
Attachment #8644714 - Flags: review?(vladimir)
(Assignee)

Updated

3 years ago
Attachment #8644711 - Attachment is obsolete: true
Attachment #8644711 - Flags: review?(vladimir)
(Assignee)

Updated

3 years ago
Attachment #8644712 - Attachment is obsolete: true
Attachment #8644712 - Flags: review?(vladimir)
(Assignee)

Updated

3 years ago
Attachment #8644713 - Attachment is obsolete: true
Attachment #8644713 - Flags: review?(vladimir)
(Assignee)

Updated

3 years ago
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
(Assignee)

Comment 13

2 years ago
(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]
(Assignee)

Updated

2 years ago
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)
You need to log in before you can comment on or make changes to this bug.