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

Re: [Public WebGL] WebGL BOF at SIGGRAPH

We do support mobile platform in PlayCanvas all the way, and by default do not respect DPI, unless the developer made settings changes in a project to respect DPI.
This is because as Floh mentioned - on Mac's any WebGL content in retina, will not look much different, but will get very bad performance indeed. And on mobile it is actually similar issue. It is visually more apparent that resolution is low, but developer can actually find a middle ground if they want.

What we've seen, mid mobile device is not capable of 60 fps on any medium complexity content in high DPI.


On 18 July 2017 at 18:09, Floh <floooh@gmail.com> wrote:
Apologies for chiming in, but from my experience on my mid-2014 13" MBP, WebGL demos which render at Retina resolution almost always have very poor performance unless the fragment shader is extremely simple (like just passing through an input color).

The puny Intel GPUs in Macs simply don't have enough oomph to render at full resolution :/ I think the default to render at half resolution is actually sensible on Macs (at least Macs with Intel GPUs), if possible with 4x MSAA to get some image quality back.


On Tue, Jul 18, 2017 at 1:22 PM, Jukka Jylänki <jujjyl@gmail.com> wrote:

Hey Christophe,

We've discussed with Unity's team in the past about making the html
pages high DPI aware. I see in the Doll demo, the content is still
rendering WebGL to the CSS pixel resolution. This means that on
"retina" OS X displays and on Windows where DPI scaling is enabled and
> 100%, the WebGL content is not full resolution, but upscaled lower
res, as if it had been renderer to "Standard definition" and then
upscaled to high DPI.

There is a Khronos article about CSS pixels vs WebGL canvas pixels
here: https://www.khronos.org/webgl/wiki/HandlingHighDPI

In general all web APIs deal with just CSS pixel units, but WebGL is
special, since it deals with physical pixels. The WebGL canvas size is
defined in physical pixels. The value window.devicePixelRatio gives
the scaling factor that is needed for translating CSS pixels to
physical pixels, so a value of 2 denotes a 2x upscaled retina display.

I think it would be good if Unity always rendered to high DPI
resolution to match the exact display pixels 1:1 without upscaling. In
the Doll demo, I see that the canvas is <canvas style="cursor:
default;" id="#canvas" width="720" height="480"></canvas>, and the box
model display shows the CSS size of the canvas to also be 720x480,
though on my browser at 100% zoom level, window.devicePixelRatio is
1.5, which means that the actual physical screen surface area that the
canvas is taking up on my display is 1080x720, and it's being
stretched over by WebGL content coming from a 720x480 backbuffer.

There's three difficult caveats that developers should be mindful of
when implementing high DPI support, that might not be obvious from the
Khronos article:

a) window.devicePixelRatio is not an immutable constant. In
particular, it changes when you zoom the browser view in or out.
Therefore only reading it only once at page startup will not be
guaranteed to stay true if user zooms in, or navigates to the page
with browser pre-zoomed and then later resets the zoom level. Browser
resize event should fire when one zooms in or out to catch this, iirc.

b) window.devicePixelRatio does not need to be an integer. The article
shows a simple-looking rational number such as 1.5, though
window.devicePixelRatio might not be like that either. If one zooms
in, it can be anything like 1.413513x, and on some mobile devices,
we've seen 1.336666x and similar "arbitrary" looking values, so
treating as integer or integer/integer rational would be trouble.

c) If one wants to render WebGL content matched 1:1 from WebGL
backbuffer to physical pixels on screen, the process of matching the
WebGL canvas size to its CSS pixel size is a delicate process. The
root issue is that the CSS pixel size of a canvas can be an arbitrary
double with fraction parts, whereas the WebGL backbuffer size need to
be an integer. This means that when converting CSS size to backbuffer
size, one needs to do a double->int conversion, which introduces
rounding. DOM element compositors seem to happily composit
subpixel-sized elements, which means that some CSS sizes for canvases
just will not line up with any integer size for a canvas. I'm not sure
if the WebGL spec would have any special considerations here, though
more details at https://github.com/KhronosGroup/WebGL/issues/2460.

This was an action item at some point for Unity team to add high DPI
support, though I wonder if it was backlogged, or perhaps it was
implemented as an option to Unity that the Doll demo build did not


2017-07-18 11:29 GMT+03:00 Christophe Riccio <christophe.riccio@unity3d.com>:
> Hi,
> I updated the demo so that it's a little more reasonable size (13 MB):
> http://files.unity3d.com/christopheri/webgl_linear/index.html
> Here is the a link if you want to download the demo:
> https://oc.unity3d.com/index.php/s/IDkAebELenpddHq
> Thanks,
> Christophe
> On Thu, Jul 13, 2017 at 8:46 PM, Kenneth Russell <kbr@google.com> wrote:
>> On Thu, Jul 13, 2017 at 11:22 AM, Maksims Mihejevs <max@playcanvas.com>
>> wrote:
>>>> Let's be nice to our colleagues and competitors. Unity is a partner in
>>>> the WebGL ecosystem helping to move things forward, as is PlayCanvas.
>>> Absolutely! And because of Unity, there is a lot of progress in the web
>>> space, which is great!
>>> I just believe that web is unique on its own platform, and requires
>>> honest understanding of its specifics and user behavior on it. And success
>>> of WebGL platform depends a lot on tools and engines to value specifics of
>>> that platform: keeping builds small to save waiting times and traffic,
>>> respect casuality of users behavior on the web and don't brick
>>> browser/mobile by simply navigating the web.
>>> I honestly wish Unity and other similar engines will be able to solve
>>> their challenges and allow creatives to create amazing content with huge
>>> reach to the web audience.
>> Me too. The larger engines like Unreal and Unity that compile to
>> WebAssembly bring a large feature set but also carry a high download cost.
>> PlayCanvas has shown amazing results in a small amount of code, with assets
>> targeted for fast startup. I hope PlayCanvas will continue to advance their
>> feature set at the same time that the other engines try to trim down their
>> size.
>> -Ken
>>> -Max
>>> On 13 July 2017 at 18:34, Kenneth Russell <kbr@google.com> wrote:
>>>> On Wed, Jul 12, 2017 at 6:33 AM, Christophe Riccio
>>>> <christophe.riccio@unity3d.com> wrote:
>>>>> Hi Kenneth,
>>>>> If you want to show our small WebGL 2.0 demo:
>>>>> http://files.unity3d.com/christopheri/webgl_linear_default/index.html
>>>> Hi Christophe,
>>>> Thanks, we'll plan to show it at the beginning of the BOF!
>>>> On Thu, Jul 13, 2017 at 4:18 AM, Maksims Mihejevs <max@playcanvas.com>
>>>> wrote:
>>>>> Don't want to sound harsh, but 100Mb+ for a static model with a bit of
>>>>> post effects with freeze of browser for at least 10 seconds at the end of
>>>>> the load, is not a great showcase for anything "web friendly".
>>>> Hi Max,
>>>> Let's be nice to our colleagues and competitors. Unity is a partner in
>>>> the WebGL ecosystem helping to move things forward, as is PlayCanvas.
>>>> -Ken

You are currently subscribed to public_webgl@khronos.org.
To unsubscribe, send an email to majordomo@khronos.org with
the following command in the body of your email:
unsubscribe public_webgl