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

Re: [Public WebGL] WebGL Antialiasing



Also, is not gl.getParameter(gl.SAMPLES) a way to check how many multisampling samples you're getting?

----- Original Message -----
From: "Benoit Jacob" <bjacob@mozilla.com>
To: "public webgl" <public_webgl@khronos.org>
Sent: Saturday, November 24, 2012 8:02:20 AM
Subject: Re: [Public WebGL] WebGL Antialiasing


On 12-11-24 06:52 AM, Steven Wittens wrote:
> I was wondering if people here could shed some light on the reasoning behind the antialiasing flag in WebGL, namely:
>
> - Why is the flag considered a request which may be ignored?
Because doing WebGL anti-aliasing at a reasonable performance cost
(which excludes FSAA) and without quality degradation for some types of
graphics (which excludes FXAA) leaves only MSAA and its variants;
availability of that depends on the underlying GL, and is not universal.
Moreover, even when it is available, bugs in certain drivers can force
browser developers to blacklist it and force non-anti-aliased WebGL.
That is for example the case on a majority of Mac drivers. Making
antialiasing mandatory would therefore severely limit availability of WebGL.

> - Why are you incapable of inspecting or controlling the applied quality level of MSAA?
That part might be up for discussion. It might be reasonable to let the
application hint whether it wants low- or high- quality antialiasing. It
should also be possible to give a getter for that. However, I would be
wary of phrasing it in terms that make it MSAA-specific as the current
spec does not force implementations to use MSAA to implement antialiasing.
> - Why are you incapable of checking if the request has been satisfied?

That's not true, you are capable of checking if it is satisfied: after
context creation, getContextAttributes will return the actual context
attributes, so it should have antialias if and only if you do have
antialiasing.

Benoit

>
> My use case is that I'm rendering 3D vector graphics with WebGL. Without anti-aliasing, it looks terrible. But because the scenes are very simple, I could easily go for high levels of MSAA and still get acceptable performance. This is particularly important because on the systems I've tried, "antialiasing: true" also triggers higher quality line rendering (similar to GL_LINE_SMOOTH in traditional OpenGL). And to make it worse, the latest Chrome nightlies have decided to disable anti-aliasing entirely for nVidia chipsets on OS X for security reasons with the driver.
>
> See e.g. http://acko.net/files/mathbox/MathBox.js/examples/BezierSurface.html
>
> These days, anti-aliasing is a big deal in real-time rendering, and there is an entire zoo of techniques to be applied, from post-processing filters like FXAA/MLAA to custom multisample resolvers like SRAA/TXAA/etc. Performance and image quality can vary enormously based on the level of hardware multi-sampling, ranging from awful-but-fast (2xMSAA), to acceptable-and-performant (4+4xCSAA) to gorgeous-but-slow (16xMSAA, 2 or 4xSGSSAA). And on the web, it is more likely than on the desktop that WebGL scenes will be embedded in webpages as small renders, rather than 720p or 1080p scenes where AA is less essential.
>
> At the very least, WebGL developers should have the ability to detect whether antialiasing can actually be applied and to what degree. That is, how many color/depth/stencil samples, how many coverage samples, etc. That way, if the native implementation is insufficient, they can replace it with a custom post-processing filter, possibly in combination with super-resolution rendering. I could easily see myself doing a quick off-screen rendering benchmark to determine optimal settings. Right now I can't, because I'm working blind.
>
> Steven Wittens
>
>
> -----------------------------------------------------------
> 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
> -----------------------------------------------------------
>


-----------------------------------------------------------
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
-----------------------------------------------------------


-----------------------------------------------------------
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
-----------------------------------------------------------