[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 Mon, Jun 18, 2012 at 6:23 PM, Mark Callow <callow_mark@hicorp.co.jp> wrote:

On 19/06/2012 05:30, Kenneth Russell wrote:
Because the canvas's intrinsic dimensions are its width and
height interpreted as CSS pixels, WebGL applications not specifically
written for high-DPI displays will just work. They'll render at a
lower resolution and be scaled up. The canvas's relative size on the
web page, and how it participates in layout, will be unchanged on
high-DPI displays.
{Open,Web}GL are resolution independent APIs.

Not they aren't. As has been pointed out several times now. gl_FragCoord, gl_PointSize, glLineWidth are not resolution independent nor are glViewport nor glScissor


 
The behavior described above is not "just work(ing)". It is broken. It is going to make many WebGL programs look like shit.

The majority of WebGL programs only need to know the pixel size of the drawing buffer in order to set the viewport. If the viewport was set automatically from the  canvas size (with css pixels converted to device pixels by the implementation) then that majority of apps would truly "just work".

Any apps that use gl_Fragcoord, gl_PointSize or glLineWidth would break.

 

The remaining apps, those doing computations with gl_fragCoord, using point size, line width or scissor would need to query the size of the drawing buffer in order to get their computations correct. They need to do that today.

No they don't. Otherwise none of them would be working and yet we have thousands of WebGL pages working just fine

 
Any that don't are broken and we should not try to magically make them work.

I think we need to do the following:
  1. Require WebGL implementations to scale the CSS pixel size of the canvas to device pixels to determine the size of the drawing buffer it will allocate.
  2. Change the sample applications to make their canvases some percentage of the page/browser window size rather than a fixed pixel size. In this world of a vast array of screen sizes and resolutions (dpi values) this is what just about any application should do. We need to lead by example.
  3. Set the viewport automatically to the size of the drawing buffer whenever it changes. I can't conceive of a correctly working application using a smaller viewport that would not need to modify that viewport whenever the canvas changes size so automatic (re)sizing should not inconvenience those applications.
Regards

    -Mark