[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Public WebGL] HI-DPI displays and WebGL issues

On Jun 19, 2012, at 6:32 PM, Dean Jackson wrote:

On 20/06/2012, at 11:11 AM, Gregg Tavares (社用) wrote:

This brings up a bunch of new questions

What should this do?

   gl.texImage2D(......, canvas) 

For compatibility it should upload a CSS pixel version of the canvas. 

There likely is less WebGL content that would be broken if you chose to return device pixels here, but for consistency CSS pixels seems like the right thing.

I'm not sure why. If I set the canvas size to 250x250, I would expect to get a texture of that pixel dimension uploaded. On a HiDPI device that might mean the canvas image would have to be scaled down to meet that criteria, but I think that's fine as a compatibility mode. If you want to opt-in to a higher res canvas (from WebGL's standpoint) then you can use one of the new ways of specifying that mentioned earlier in this thread.

I don't think it will be possible fully, but I think we need to break as little content as possible on HiDPI devices. I think the amount of content that gets tricky with read-back and other subversive techniques where the actual dimensions get exposed is much smaller than content which just wants to make sure the shaders are dealing with the pixel dimensions they expect.

In general I'm not a fan of auto-doubling the backing store. It gets very confusing. The user needs to detect a bunch of things before knowing what will happen. With WebGL it gets even more tricky - what should MSAA do? Produce 16x the backing store?

Whatever solution we provide, it should not be an "HD" solution or a "2x" solution. It should be a solution which separates, once and for all, the notion of actual pixel dimensions of the buffers used by the GPU from everything outside the WebGL context. We just need to get rid of the notion that the current ways of specifying image and canvas sizes have anything to do with the actual pixel dimensions of the incoming media.