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

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

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.

Set dependency on incorrect bug, reverting.

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.

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.

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.

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.

Bug 1157984 - Part 4: Remove gfxRect::TransformBounds

(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.

Ugh, wrong bug.

(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?

(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/.