User Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:53.0) Gecko/20100101 Firefox/53.0 Build ID: 20170209004018 Steps to reproduce: Using canvas 3D context (WebGL). When the rendering canvas size is quite big, above a certain size the 3D drawing area is cropped (to quarter size of the rendering canvas). If you lower the width of the canvas, the height limit increases, and vice versa. It seems that critical values are different depending on the computer used, the webpage in which canvas is inserted, if debug console is opened embedded or not… This does not happen in other browsers. You can reproduce the issue on this page : http://hapticmedia.fr/demo/work/canvas_bug/index.html Increase or decrease width and height values to find critical limits where 3D area is cropped (you can change one value at a time and play with different compbinations to see that the limit is not linked to a particular width or height, but combination of both). Actual results: When styling a large canvas, the canvas has the right size but the 3D rendering area is cropped to quarter size of the rendering canvas size. Expected results: The 3D rendering area should have same size as the canvas.
It works fine with HWA disabled. Reg range: https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=b7eb1ce0237d&tochange=0e441ff66c5e I think the regression is due to bug 854296.
It works with webgl.angle.try-d3d11=false too.
I would have thought bug 8538530 or even at pinch bug 1049138 more likely candidates than bug 854296.
Before bug 1079398, 4000x3000 SVG is rendered fine. After bug 1079398, it's blank (works with webgl.angle.try-d3d11=false). After reg range from comment #1, 4000x3000 SVG is rendered cropped (quarter size).
You need to log in before you can comment on or make changes to this bug.