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

Florian Bösch [email protected]
Sat Dec 1 02:48:26 PST 2012


I don't think you can shim AA from JS-userland for a couple of reasons

1) It would be contingent to know when a user has finished drawing, which
we don't.
2) It would imply substituting the actual front buffer with an FBO (perhaps
we can monkey patch gl.bindFramebuffer and ask for null or something)
3) Some anti-aliasing techniques (like SSAA and geometric aa) can only be
done in userland if the whole scene is drawn multiple times (with offsets)
which requires deep changes in a users shaders and renderloop.
4) Other anti-aliasing techniques rely on the presence of depth, normal and
color. The depth could be obtained by faking the front buffer and attaching
a depth texture, the normal however would again require deep changes in a
users code.

That leaves at least some techniques (FXAA for instance) if you can solve
#1 which afaik we cannot.


On Sat, Dec 1, 2012 at 4:29 AM, Gregg Tavares (社用) <[email protected]> wrote:

> Just an idea, but someone could write a stub js library.
> AlwaysGiveMeAntiAliasing.js
>
> That would check if the driver gave an anti-aliased backbuffer and if not
> magically faked it with one of the mentioned workarounds.
>
> Fun weekend project?
>
> Even if the bugs get fixed there are reasons you might want to use the
> other techniques
>
> http://www.iryoku.com/smaa/
> :-)
>
>
> On Sat, Dec 1, 2012 at 5:31 AM, Tony Parisi <[email protected]> wrote:
>
>> Hi all
>>
>> Thanks for the extra color on this (very important) topic
>>
>>
>> On Fri, Nov 30, 2012 at 10:08 AM, Dean Jackson <[email protected]> wrote:
>>
>>>
>>> On 01/12/2012, at 5:00 AM, Dean Jackson <[email protected]> wrote:
>>>
>>> If you are passionate about getting this fixed you need to make noise
>>> where Apple can hear you.
>>>
>>>
>>> .... and that place is
>>>
>>> http://bugreporter.apple.com/
>>>
>>> If antialiasing is important to you please file a report there. Maybe
>>> Ken could share the bug ids that he filed on this? That way any new bugs
>>> could reference them which helps them get screened faster.
>>>
>>> Don't worry about filing duplicates. Consider that a vote for the
>>> importance. Also, don't be put off by the fact you'll likely get told it is
>>> a duplicate and then not see any updates. That's an unfortunate part of our
>>> external bug system. Be assured that Apple really does notice and track
>>> everything filed on that site.
>>>
>>> This goes for all Apple OpenGL and WebGL bugs (including "Please support
>>> WebGL").
>>>
>>>
>>> Sorry for the email flood but there is one last thing. If you do file a
>>> bug on WebGL, please note the bug id and email it to me (off-list). The
>>> people who screen our bugs are not necessarily experts in whatever the
>>> topic is, so I can maybe help it get processed faster. Also, I want to know
>>> about any problems with WebGL :)
>>>
>>> Dean
>>>
>>>
>>> Oh, and please attach a complete system profile. It's essential that we
>>> know your hardware and OS configuration.
>>>
>>>
>>>
>>
>>
>> --
>> Tony Parisi                             [email protected]
>> CTO at Large                         415.902.8002
>> Skype                                     auradeluxe
>> Follow me on Twitter!             http://twitter.com/auradeluxe
>> Read my blog at                     http://www.tonyparisi.com/
>>
>> Read my book! *WebGL, Up and Running*
>> http://shop.oreilly.com/product/0636920024729.do
>> http://www.amazon.com/dp/144932357X
>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://khronos.org/pipermail/public_webgl_khronos.org/attachments/20121201/8344a943/attachment.html>


More information about the public_webgl mailing list