Querying the max size of the drawing surface?

[Philip Rideout]

We've observed that Firefox and Chrome have issues when the canvas drawing surface is wider or taller than 4096 physical pixels.  Large canvas elements are fine, mind you; I'm talking about the drawing surface.

It's easy to observe this on an iMac Retina;  Firefox seems to crop the drawing surface and Chrome stretches it.  This is unsurprising because of the sophisticated compositing that goes on behind the scenes.

Is there a way of determining this limit so that developers can adjust their WebGL viewport in the right way?  I don't think MAX_VIEWPORT_DIMS is the right thing to query for; it returns 16384 on both browsers.  This feels more like it would be part of the HTMLCanvasElement API than the WebGLRenderingContext API.

Thanks,

Philip Rideout

Senior Graphics Developer

mappable.com

[Kenneth Russell]

Querying WebGLRenderingContext.drawingBufferWidth and
drawingBufferHeight will tell you the exact size of the context's
drawing buffer. I'm afraid there's no way to query the maximum ahead
of time, although no browser will allocate a back buffer larger than
gl.getParameter(gl.MAX_TEXTURE_SIZE) in either width or height.

There have been some attempts to increase this to 8192 in Chrome in
http://crbug.com/445542 , but conformance tests keep breaking on
various platforms. We've been told that it's infeasible to recover
from GL_OUT_OF_MEMORY errors on some platforms, so we would need to
enable the larger drawing buffer size only on platforms where a large
monitor is attached.

-Ken

> --
> You received this message because you are subscribed to the Google Groups
> "WebGL Dev List" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to webgl-dev-lis...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

[Philip Rideout]

Thanks Ken, this is exactly what we needed.  It was right there in the WebGL spec and I never noticed it.  :)

You received this message because you are subscribed to a topic in the Google Groups "WebGL Dev List" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/webgl-dev-list/AHONvz3oQTo/unsubscribe.
To unsubscribe from this group and all its topics, send an email to webgl-dev-lis...@googlegroups.com.

[Alecazam]

There are still cases where an 8k x 1 texture or 16k x 256 texture would be useful. Neither of these cases would exhaust vram. The FF 4k limit applies to render and offscreen buffers and is only hacked on Intel/Nvidia. Last I looked AMD and cube maps on all could still get to 16k actual max size.

[Jeff Dash]

IIRC, Firefox will occasionally give you a backbuffer larger than the value returned to WebGL for gl.MAX_TEXTURE_SIZE.

This is sometimes because the MAX_TEXTURE_SIZE (or max acceptable/safe texture size) of the underlying driver is non-power-of-two, and because the WG decided that MAX_TEXTURE_SIZE for WebGL must be a power-of-two.

I believe this is still true on some OSX machines.

Firefox does not have a universal 4k hard limit on MAX_TEXTURE_SIZE, though it is restricted to 4k on some hardware.

On Sun, Aug 2, 2015 at 10:57 AM, Alecazam <al...@figma.com> wrote:

There are still cases where an 8k x 1 texture or 16k x 256 texture would be useful.  Neither of these cases would exhaust vram.  The FF 4k limit applies to render and offscreen buffers and is only hacked on Intel/Nvidia.  Last I looked AMD and cube maps on all could still get to 16k actual max size.

[Brandon Jones]

I landed a change in Chrome today that tweaks this behavior a bit. We've had some trouble removing the buffer size restriction entirely, due to it triggering Out of Memory errors on our testing infrastructure. Instead we're trying a change where we restrict backbuffer based on a total area of 4096*4096 pixels rather than clamping to 4k in each dimension. If the total pixel count exceeds that limit the buffer is scaled down to the largest possible dimensions that fall under the limit keeping the aspect ratio. This allows for full resolution 5120*2880 iMac Retina screens, and will handle absurdly large sizes more gracefully. (Texture dimensions will still clamp to hardware advertised texture limits, though, so you still can't do a 32k*1 canvas. Sorry!)

--Brandon

[Alecazam]

Brandon, that seems like a good first start.  At lot of times even with a 4K display, you may need a little extra buffer space.   It still feels like having tests run out of memory shouldn't be a reason to artificially limit the hardware returned sizes.  There are more and more cards with 8GB and more.  A 16kx16kx4 texture is 1GB.  A 4kx4kx16 (RGBA32f) is 264 MB.  They're all big.

Jeff, FF is still clamping Nvidia/Intel to super low limits on OSX.  My 750m can do 16K on a side, but FF reports 4K.  This was only based on the vendor id, so it left no room for newer drivers to fix the issue.  The comments indicated that it was due to getting garbage buffers returned, but it would be better for FF to just clear those buffers (like Chrome's deferred clears).  Using Chrome returns the full 16K on the same system.  I added some commentary to the Mozilla bug on the issue.   That's a pretty good chunk of the GPU market to clamp down.  This affects gl.MAX_RENDERBUFFER_SIZE and gl.MAX_TEXTURE_SIZE both.  So it's not just the backbuffer, it's offscreen textures too.

[Jeff Dash]

This restriction is not something that clearing (which all implementations already do) can fix. It's an issue with some drivers where out-of-bounds accesses due to large resource sizes results in exposure of other GPU resources, in some cases including contents of the machine's desktop. Because of this severity, it is a restriction which we must be very careful in lifting.

It sounds like Chrome has expanded its whitelist in this regard, so we should just need to resync with that. There is still some double-checking we need to do on our end, but we can take another look.

[Alecazam]

If it is a problem then Chrome would hit it or FF would with 16k cube maps (which are strangely unclamped and 6x or 8x larger). An OSX version test would help on those clamps and the Intel cube map limits are super small. I'd appreciate any fixes on this and/or shader_texture_lod exposure on OSX. These are hard issues for devs to work around.

[Jeff Dash]

Chrome did hit it in the past, and cube maps are not affected by this problem on all platforms. If you have further technical questions, please post in the relevant bug.

I'll take another look at raising these, time permitting.

On Aug 5, 2015 12:06 AM, "Alecazam" <al...@figma.com> wrote:

If it is a problem then Chrome would hit it or FF would with 16k cube maps (which are strangely unclamped and 6x or 8x larger).  An OSX version test would help on those clamps and the Intel cube map limits are super small.  I'd appreciate any fixes on this and/or shader_texture_lod exposure on OSX.  These are hard issues for devs to work around.