Chrome vs Safari disappearing objects

[Afterlife7481]

Running three.js revision 59
The code that I am running is basically a modified version of your periodic table example but with loads more objects of bigger size

I have tested this on several computers, OS and browsers and it seems that while

http://www.onthefuckingmoon.com/2013/

renders perfectly well on SAFARI it fails to display all the objects on CHROME (the exact same happens for chrome running on windows and os x)

here is a video of the bug: http://www.youtube.com/watch?v=nxv6c3K7vVE

You will need to zoom out to see the objects disappearing in CHROME

Please note that if I reduce the size of each object, then then will render fine on Chrome, so I think this is linked not only to the number of objects but also the size.

I am thinking this may be a bug, I hope this is the right place to report such anomaly.

Thanks

[arodic]

This bug keeps coming back in various shapes and forms.

I made a test case for this long time ago mentioned in Issue #3546
http://aleksandarrodic.com/p/css3dbug/

Here is the chromium bug. Please vote for it to be solved.
https://code.google.com/p/chromium/issues/detail?id=222926

[Afterlife7481]

Thank you arodic, you are right this is probably a chromium bug.

I added a video of the bug for those interested: http://www.youtube.com/watch?v=nxv6c3K7vVE

All the best,
Tim

[Afterlife7481]

update from chromium:

https://code.google.com/p/chromium/issues/detail?id=222926

#9 shawnsingh@chromium.org
I spent today debugging this, and diagnosed what's going wrong.

(1) when we compute visible content rect, we are returning an empty rect when the layer's draw transform is uninvertible. We should consider returning the full layer_bounds here instead. It will indeed cost extra painting, but there may exist cases where this uninvertible transform can still be rendered - the gl_renderer actually does a hacky flattenTo2d operation, which could make that uninvertible matrix into an invertible one that can correctly be rendered.

(2) After solving #1, gl_renderer was still getting uninvertible matrices. Then I found the real root of the bug here - many values of the matrix are becoming quite small. As a result, the determinant is also small, and causes the code to think that the matrix is uninvertible when it actually is invertible.

I was able to solve this by normalizing the matrix on-the-fly (scale all elements proportionally so that the 4th row, 4th column element is 1). However, this will add 1 division and 16 multiplications to the computation of IsInvertible() and GetInverse(). This is tolerable, but not desired...

One hacked option that I can think of: we can do a slightly imprecise normalization that only requires one division (which can likely be masked by other operations in the instruction pipeline in this version) and one multiplication. The tradeoff is that we may still hit the uninvertible transforms due to imprecision, though the chances of it occurring are significantly reduced.

[arodic]

shawnsingh@chromium.org fixed it. The patch is coming!