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

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

On 12-11-30 11:56 AM, Tony Parisi wrote:
Hi all,

Any progress on a permanent resolution for this bug?

This is a huge deal for some of us. In my case, I have beautiful demos that got un-beautiful recently when my Chrome and Firefox updated. I might have to (shudder) show them on a Windows machine instead. But that only helps with hands-on demos... if I'm sharing links, and the user has a Mac, I'm SOL. The differences between the two experiences is stark. In fact, no antialiasing is pretty much a killer for me and the business I am trying to get funded as we speak. Without it, WebGL is fairly useless, a step back to the horrible old days of the late '90's trying sell 3D when the final image didn't look as good as a Flash animation. We *can't* go back there.

I am also about to embark on a second O'Reilly book, more in-depth than Up and Running. The book has a heavy focus on 3D as a user interface technology and it is positioned as a general visualization book, not just about games. As such it would be hard to hide the lack of antialiasing. And I would really hate to have to apologize around this issue to the readers.

If Apple isn't going to fix it soon, is there any chance we could ask the browser makers to de-implement the current fix, or at least somehow make it conditional with a different antialias flag or a "really, I mean it, I want antialiasing!" API call???

The issue here is that if we don't blacklist anti-aliasing on Mac, scripts can proceed as follows:
  - get a WebGL context with anti aliasing
  - the driver bug gets some video memory contents to accidentally land into a multisample renderbuffer
  - call webgl.readPixels to obtain that video memory.
This is a severe security flaw. It affects all OpenGL applications running on Macs, but browsers are specially affected in that they must guarantee security in the face of arbitrary malicious WebGL calls. Adding a flag for "really, I mean it, I want antialiasing!" would completely reopen the security flaw, as malicious scripts would simply use it.


This is a really bad development.


On Wed, Nov 7, 2012 at 4:31 AM, Bill Baxter <wbaxter@google.com> wrote:
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.)

Well, we're only somewhat insulated from it.  Lack of MSAA still means you get some distracting flickering as the first few samples are accumulated.

And I did try using FXAA on MapsGL as an experiment at one point, and you are right that it doesn't work well for that type of content at all.


Tony Parisi                             tparisi@gmail.com
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