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

Re: [Public WebGL] Antialiasing being disabled on some Mac OS hardware



I agree with Ken that FXAA isn't an appropriate MSAA replacement in all cases, but it's an intriguing thought nonetheless.

One interesting approach is that the nature of FXAA and friends means that if you really wanted it a developer could add it to their WebGL app without the need for browser support. It could also be reasonable to inject a Post-process AA method into almost any WebGL canvas via a browser extension. I've actually looked into building something like that before and it appears that the biggest stumbling block is detecting when a frame is finished and about to be presented to the screen, which is the point that you want to run your AA pass. You can reasonably guess at when that will happen by shoving some hooks into setTimeout/requestAnimationFrame (which is what extensions like Ben Vanik's WebGL Inspector are forced to do), but that won't catch things like rendering that's triggered by mouse or keyboard input. Still, it would be appropriate for most apps, and if we could get a "about to present" event from the browser it could be made 100% reliable.

(For the record, I've already brought this topic up on the mailing list before: https://www.khronos.org/webgl/public-mailing-list/archives/1201/msg00167.html)

Of course, a browser extension isn't as desirable as having built-in support for a feature, and it doesn't address the desire to have deeper access to hardware AA methods, but it could function as a useful stop-gap solution for individuals who are willing to make the visual trade-offs involved.

--Brandon

PS: For anyone on the mailing list not familiar with FXAA read up on it here. Or check out a similar technique, SMAA.


On Tue, Nov 6, 2012 at 2:41 PM, Kenneth Russell <kbr@google.com> wrote:

Potentially -- but I personally would not be comfortable substituting
FXAA for MSAA as Chrome's antialiasing implementation for WebGL. It
doesn't provide high quality enough results in all cases. I'm thinking
about MapsGL in particular, which draws fine vector lines and text.
(As it happens, the MapsGL team has implemented their own iterative
antialiasing algorithm, insulating themselves from this change to the
WebGL implementation.)

One developer suggested on http://crbug.com/137303 that WebGL should
just expose all of the antialiasing options on the hardware and let
the developer choose. Maybe this is something that should be discussed
here.

-Ken


On Tue, Nov 6, 2012 at 2:07 PM, Florian Bösch <pyalot@gmail.com> wrote:
> WebGL surfaces being FBOs anyway, couldn't you have a fallback AA (like
> FXAA) in this case (and cases like it)?
>
>
> On Tue, Nov 6, 2012 at 10:58 PM, Kenneth Russell <kbr@google.com> wrote:
>>
>>
>> WebGL community:
>>
>> This email is public notification that support for antialiasing is
>> being disabled in some WebGL implementations, and on some hardware, on
>> Mac OS. The affected machines are those with NVIDIA and Intel GPUs.
>>
>> The MapsGL team at Google reported a bug some time ago (
>> http://crbug.com/137303 ) in which rendering would occasionally be
>> corrupted. Brandon Jones from the Chrome team at Google successfully
>> created a reduced standalone test case which provokes the problem, and
>> has filed two bugs with Apple.
>>
>> Unfortunately, once the problem was understood, given its nature it
>> was necessarily to immediately disable antialiasing support in the
>> WebGL implementation. This has already been done in Chrome, and we
>> expect that other implementations will follow soon. Brandon has also
>> added a new WebGL conformance test which successfully provokes the
>> problem the majority of the time, which will be used as a regression
>> test.
>>
>> I am disappointed to have to convey this news as it will adversely
>> affect the rendering quality of all WebGL applications. I hope for a
>> speedy resolution to the bugs that have been filed, and look forward
>> to re-enabling antialiasing support in WebGL on these hardware
>> configurations as soon as possible.
>>
>> If you encounter WebGL developers surprised by this change, please
>> point them to this thread in the mailing list archives:
>> https://www.khronos.org/webgl/public-mailing-list/archives/ .
>>
>> Thanks,
>>
>> -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
>> -----------------------------------------------------------
>>
>

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