|
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.
Benoit
This is a really bad development.
Tony
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.
--bb
--
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
http://shop.oreilly.com/product/0636920024729.do
http://www.amazon.com/dp/144932357X
|