Test case, please.

From what I can tell looking at the code I would expect the backing store (drawing buffer in WebGL terms) to match the width/height attributes on the canvas.

http://www.webkit.org/blog-files/3d-transforms/poster-circle.html reproduces this for me on mac at least.

That's not WebGL

…

I see this on mac, on all pages. That's caused by RWHVMac missing a call to setWantsBestResolutionOpenGLSurface:YES. If I add this, the IOSurface that the gpu process sends for the compositor output covers only half the width and height of the window though.

This seems to work now, at least on Mac.

Reopen if you still see this.

WebGL is still pixel doubled on ChromeOS (eg. http://get.webgl.org) in the following version:

Google Chrome	21.0.1180.1 (Official Build 142960) canary
Platform	2465.0.0 (Official Build) canary-channel link
WebKit	537.1 (@120591)

Ian, any idea what's required to fix this?

It's rendering exactly what the page asks for (i.e. it's setting the width/height to match the number of CSS pixels).  Maybe Gregg knows how to update that sample to be deviceScaleFactor-aware?

I can't get WebGL to work at all on the latest Mac canary (22.0.1181.0).  Nico, what site did you use to verify WebGL was working in high-DPI on Mac?

rbyers: WebGL Aquarium

jamesr, gman (and rest): For Canvas2D, apple suggest the following logic to decide if manual pixel doubling through CSS should be done:

// To create a 400x300 canvas:
if ( window.devicePixelRatio ) {
  // LoDPI display, set canvas size to 400x300
} else {
  var context = myCanvas.getContext("2d");
  if (context.webkitBackingStorePixelRatio == 1) {
    // currently the case on iOS. Set canvas size to 800x600 to get 800x600
    // pixels, then size it to 400x300 via css. (XXX)
  } else {
    // current mac hidpi path. Create canvas in 400x300,
    // it's transparently created with 800x600 pixels instead
  }
}


It's conceivable they want to move iOS to the mac model too. I don't know if something like that is feasible for webgl.

rbyers: For WebGL, pages currently have to do the path marked with (XXX).


(I think this bug is WontFix; maybe you want to repurpose it for discussing if the canvas2d if webkitBackingStorePixelRatio trick could work here. Probably not, as OpenGL is kind of pixel based.)

This has been discussed to death on the public-webgl list. Auto-doubling (like Apple is doing with canvas 2d) is not feasible for WebGL.  If the WebGL content sets a backing store size that is equal to the CSS pixel size times the device scale, then you can get 1:1.

For reference the short answer is

In OpenGL/WebGL, gl_FragCoord, gl_PointSize and glLineWidth are all in device pixels. So, unlike the canvas2d API, there is no way to hide the backbuffer size. If the browser chose a size different than the user asked for many many WebGL apps would break.

WebGL apps already choose there own sizes often at a higher or lower resolution than is displayed. Examples:

http://glsl.heroku.com has a resolution setting 
2  = 1/2 
1  = 1:1
.5 = 2:1 (or 1:1 on an HD-DPI display

All the samples by me at http://webglsamples.google.com render to a 1024x1024 backbuffer. If you make your window different than 1024x1024 the browser will bilinear scale composite that 1024x1024 the size of the window.

If you want the WebGL backbuffer to match the native resolution do this

    canvas = document.createElement("canvas");
    canvas.width = desiredWidth * window.devicePixelRatio;
    canvas.height = desiredHeight * window.devicePixelRatio;
    canvas.style.width = "" + desiredWidth + "px";
    canvas.style.height = "" + desiredHeight + "px";

or this

    <canvas id="foo" style="width: 400px; height: 300px"></canvas>
    canvas = document.getElementById("foo");
    canvas.width = canvas.clientWidth * window.devicePixelRatio;
    canvas.height = canvas.clientHeight * window.devicePixelRatio;
  

Perfect, thanks for the details guys.  I didn't know this had already been discussed.

This issue has been closed for some time. No one will pay attention to new comments.
If you are seeing this bug or have new data, please click New Issue to start a new bug.