[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Public WebGL] How to set a canvas backing store to display units?
On Tue, Jun 12, 2012 at 6:38 PM, Glenn Maynard <firstname.lastname@example.org>
On Tue, Jun 12, 2012 at 7:54 PM, Gregg Tavares (社用) <email@example.com>
Yes, there's some issues there. You need to know the number of device pixels in the backing store for WebGL so canvas can't automatically give you a 2x backing store for WebGL. Any program using gl.viewport or gl.scissor will break.
canvas.width/height effectively determine the window coordinate space as far as WebGL is concerned (eg. the size of the window within the page), so gl.viewport wouldn't break as long as people say gl.viewport(0, 0, canvas.width, canvas.height). If anybody's saying gl.viewport(0, 0, gl.drawingBufferWidth, gl.drawingBufferHeight), that would indeed break. That's incorrect code; hopefully it's not common. I see two hits here, which perhaps we could get fixed: https://www.google.com/search?hl=en&q=
"gl.viewport(0%2C+0%2C+gl.drawingBufferWidth%2C+gl.drawingBufferHeight" Just two hits is promising, though.
that won't work. Like I said, drawingBufferWidth and drawingBufferHeight are for the actual size. If you ask for canvas.width = 9000 and your GL can only handle 2048 you'll get 2048. At that point
canvas.width = 9000
canvas.drawingBufferWidth = 2048
If you still set gl.viewport to canvas.width you'll get the wrong results when you render.
There are conformance tests for this behavior
I think the only major place it would normally cause breakage is with gl.readPixels, where you'll need to use the dimensions of the backing store. The failure mode would probably be things like screenshots only capturing the top-left quarter of the screen. There was a proposal to deal with this in 2d canvas, which could be used here too. http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2012-March/035112.html
readPixels would be changed to take CSS pixels (rather than device pixels, as it does now), scaling the output if it's not 1:1. A new method, eg. readPixelsHD, would be added, which behaves as readPixels does now, to allow reading full-resolution data for apps that are aware of it. This would avoid breaking current code that uses readPixels. (I don't think Ian has got to that thread yet, so it's unknown for now whether 2d canvas will go that route, but it seems like a good idea to me.)
There are other things that can go wrong, but I think they're mostly nonfatal. For example, if you create a framebuffer for an intermediate rendering pass using smaller Canvas dimensions, then your app doesn't explode; it just ends up rendered at the smaller resolution, which is a much more tolerable failure case.
That said, while the idea of canvas @width/@height determining the window coordinate space makes sense from an application developer's standpoint, I have no idea how that translates in detail inside the OpenGL ES spec.