[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 Wed, Jun 13, 2012 at 6:19 AM, Glenn Maynard <glenn@zewt.org> wrote:
(Can we please merge these threads?  This is just making it harder to follow, and harder to merge subthreads, which is going to make things repetitive.)


On Wed, Jun 13, 2012 at 12:30 AM, Gregg Tavares (社用) <gman@google.com> wrote:
I don't follow.  You're *supposed* to call gl.viewport(0, 0, canvas.width, canvas.height); it shows that in an example right in the spec (2.3) and it's what everyone's doing.

The spec is wrong

The spec is right, because it's what everyone is actually doing.

"gl.viewport(0, 0, canvas.width, canvas.height)" About 11,400 results
"gl.viewport(0, 0, gl.drawingBufferWidth, gl.drawingBufferHeight)" 2 results

This only works now because the min "max size" (AFAIK) is 2048 and no one has tried to make it bigger.

Yes, by the spec, EVERYONE IS CURRENTLY DOING IT WRONG

 

It seems far too late to change this.

  If the drawing buffer is larger (high-res displays) or smaller (limited texture sizes) than the canvas, that should only affect the backing store (drawingBufferWidth), not what you pass to gl.viewport (the size of the canvas in CSS pixels).

Actually, using a larger backing store than the canvas size doesn't even seem like new behavior.  It should have the same effects as using a smaller one.

Remember, gl.viewport is not relative to the backing store. It's relevant to the size of the currently bound framebuffer OR the backing store if one is not bound.

I'm saying that that if browsers are already allowed to use a smaller backing store than the size of the canvas, then allowing them to use a *bigger* one isn't introducing anything new.

For framebuffers, the window size is equal to the dimensions of the framebuffer, but when there's no bound framebuffer it should be the CSS dimensions of the canvas, so the first line above works as everyone expects.


On Wed, Jun 13, 2012 at 12:46 AM, Gregg Tavares (社用) <gman@google.com> wrote:
In OpenGL {,ES} the coordinates for Viewport and Scissor are expressed in the space of the client area of the host window. In most (all?) cases the scale from client pixels to device pixels is 1.0 but there is almost always a translation from client pixels to device pixels.

Because setting a viewport for the backbuffer of a given size should match setting the viewport for an fbo of the same size. So should reading the pixels. With antiAlias: false the should be no difference between rendering to a 320x200 backbuffer or a 320x200 fbo of the same format.

If you want to render to a framebuffer of the same dimensions as the backing store, then that's simple: create the framebuffer texture using ctx.drawingBufferWidth and ctx.drawingBufferHeight. 

No one is doing this either so your argument that because everyone is doing gl.viewport(..., canvas.width) can't change since everyone is doing it also holds here. Everyone is making fboing canvas.width and canvas.height as well.

That argues that the browser shouldn't be able to pick a different backing store size which was the original intent. The problem drawingBufferWidth is meant to work around is the shitty canvas API that has no way to return an error if you ask for a width that's too big. Even in canvas 2d this is a problem as in canvas.width = 10000000
 
In fact, that's what people should be doing under *both* interpretations of gl.viewport().  This is unaffected by whether the drawing buffer and hardware pixels are 1:1 or not.

No it's not. blending operations, read options all matter based on pixels

gl.copyTexImage2D(..., width, height)?

What size texture do I get? Is it different if a 640x480 fbo is attached vs a canvas with width = 640x480 ?

If I update 1 pixel of that texture what with texSubImage2d( 10, 10, 1 ,1 ) how much of that texture is updated? If

OpenGL is a device pixel API not a virtual pixel API.

 


--
Glenn Maynard