something in the way

Attention, 3D fans: OpenGL in the browser has gradually gotten real. WebGL is a browser-friendly API for OpenGL graphics, and it’s pretty darned close to OpenGL ES 2.0, which in turn will be familiar to anyone doing modern mobile 3D development. WebGL isn’t part of HTML5, but HTML5 makes it possible: the Canvas element is what allows WebGL to work its magic. And WebGL goes nicely with technologies that are part of HTML5 or modern browser experiments, including the web audio API and browser video support. (The superb 20 Things I Learned About Browsers & The Web has a 3D in the browser section, well worth reading.) And you can use JavaScript (among other modern languages) to code 3D creations.

If you love the idea of sharing 3D as easily as a webpage, this is big news. It’s a huge step forward from the clunky, unpredictable, confusing use of Java for browser OpenGL, and unlike that solution, it’s part of the page on which it’s delivered, not part of a plug-in or launched app.

In recent days, we’ve seen the first stable browser with WebGL enabled by default, Google Chrome. Right now, Chrome or Firefox 4 beta are likely the easiest and most stable way to test WebGL graphics. I’ve been testing Firefox 4 beta on Linux and more recently the stable Chrome on Mac, Windows, and Linux, and it’s pretty fantastic.

Read Google’s announcement from Thursday, along with the other enhancements to Chrome:
A dash of speed, 3D and apps

Perhaps more exciting than the Chrome update is the superb Chrome Experiments, which recently added 3D goodness, from creative tools to eye candy to useful tools like an exploration of human anatomy:
WebGL Experiments

Grabbing the latest Chrome or installing Firefox beta will let you see them, but here are a couple of picks are a cool place to start, and have videos attached if you aren’t near a bleeding-edge browser:

http://www.chromeexperiments.com/detail/webgl-aquarium/?f=webgl”>WebGL Aquarium, Human Engines and Gregg Tavares

Field, Gregg Tavares

I’m pretty impressed with performance of experiments like the aquarium. I’m on a fairly low-end, last generation laptop with an NVIDIA 9500M, and they run easily.

WebGL is still early in development – Chrome is the first and only stable browser with support – but we’re getting to the phase when you could actually distribute stuff with it, and it could hit prime time very soon.

Which browsers support WebGL?

Chrome’s release is a very big deal. As I write this, WebGL is available in:

• Chrome stable, from now on
• Firefox 4.0b8 and later, meaning once Firefox 4 stable is shipped, stable Firefox, too
• Nightly builds of Safari/WebKit (which I believe includes both Mac and Windows support, though I haven’t tested on Windows)

Opera plans support, but no public build is available yet.

Microsoft appears not to be planning support for IE9, meaning it’s most likely to be odd man out … again. But you can get support for WebGL inside IE using the free Chrome Frame plug-in.

Really, if you want to try this out, installing Chrome is a good idea. It’s also no accident that Google’s Chrome Web App store means people with interesting creations have an avenue for distribution, which should soon also be true with an open Mozilla-based store for Firefox et al.

http://www.khronos.org/webgl/

Can you use Processing.js with WebGL?

Yes! Processing.js is actually a pretty decent way to fiddle around with it. The caveat is that WebGL support in Processing.js is a work in progress; if you want to get deeper, you’ll probably want to get into direct JavaScript control of WebGL. But that hasn’t stopped people from making some interesting hacks and work, and it’s a great place to start. Some demos –

A Processing.js Web IDE that uses WebGL:

– and a stunning music visualizer we’ve seen here before:

What about Google’s O3D?

O3D is some impressive technology and for many of us was the first truly compelling vision of 3D in a browser. The downside – it’s currently a plug-in. But Google does sometimes live up to their “open Web” hype. They’ve said they’re focused on improving WebGL, and that they’ll take the ideas from O3D (like its scene graph) and port to JavaScript and WebGL. There’s even an early version of the work.

It’s worth reading the (official Google) Chromium blog on the matter, partly to see how they’ve come around on JavaScript performance.

The future of O3D

Why wouldn’t you use WebGL?

This is all compelling stuff, so let’s all abandon everything we’re doing and switch to WebGL — right? Well, not necessarily:

• It’s not done yet. WebGL the spec appears pretty stable, but browser support is still forthcoming. When we (presumably) see stable Safari and Firefox builds in the near term, though, I think the whole thing will get a lot bigger.
• Universal browser support is a long ways off. Microsoft’s lack of support in IE could be a side effect of the lack of universal OpenGL drivers on the Windows platform. Whatever the reason, count out IE. And likewise, count out anyone with a capable GPU card. Even compared to the mess of video support, 3D is likely to be a “nice-to-have” feature on the Web, not the universal feature the traditional 2D page is.
• Mobile WebGL isn’t even on the table yet. So, JavaScript – yep, it’s faster on desktop computers. But mobile implementations are still evolving, mobile browsers still lag their desktop counterparts (even sometimes when they’re both based on the same Web engine, like WebKit), and performance on much less-capable mobile chips isn’t there just yet. That said, see the last bullet in this list…
• Live visuals, art will still often need “native” tools. Want to output to a second monitor, or monitors, plural? Doing something crazy like routing textures between apps? Live visualists are pushing the kinds of features that won’t be accessible immediately on the browser.
• Full-blown OpenGL isn’t available. OpenGL ES 2 is pretty great, but if you need the full OpenGL API, this isn’t designed to be that. And…
• Performance is still better with C/C++. Don’t get me wrong – performance with JavaScript is stunningly good, good enough that those Google engineers changed their assessment. But it seems to me this depends on your goals. If you’re really concerned with squeezing every last ounce of performance out of your graphics, necessary if your work is about visuals with greater complexity, this still really isn’t for you.
• This isn’t an either/or choice – OpenGL wins! Here’s the major point for me. You don’t have to choose WebGL as an exclusive solution, partly because you don’t have to choose WebGL. Invest your time in OpenGL, and learn the basic nuances when comparing, say, OpenGL 3.2 on the desktop to OpenGL ES 2 on Android and iOS to WebGL in the browser, and you can be everywhere with relatively minor adjustments.

What’s surprising to me just writing that list is, while it appears long, the advantages of WebGL are still clear, and it makes sense that some of these differences will disappear. I imagine we will still need desktop software. Google, while characterized as some sort of browser-only religion, themselves continue adding native support in their Android platform, so presumably they understand game developers and other parties want that native OpenGL access. The question may not be whether WebGL “replaces” those tools, but whether people find smarter workflows and integrated higher-level APIs to work across the platforms.

Let’s sum it up this way: if you love 3D, and if you’re an OpenGL nerd, you’re in very happy times, indeed.

And regardless, you get to watch a cool jellyfish in Chrome any time you need to unwind.

http://www.khronos.org/webgl/
http://planet-webgl.org/

Yesterday Horace Dediu tweeted:

A browser is an infinitely flexible interface, but is it the best interface for everything? Apps allow experiments in new interaction models

The browser is not the most advanced interface there is. It’s too easy to build the wrong features into something as flexible as a browser, and once a badly-designed feature gains traction it’s impossible to get rid of it. (See HTML5 drag and drop.)

So browser vendors are a tad conservative in what they support. JavaScript libraries are the main testing ground for innovation, and they’re as flexible as the browser, and can be written by one single developer.

In native development the vendor tries to force its ideas on developers; succesfully with iOS and Android, less so with other platforms. Browsers did that too back in the nineties, but meanwhile it’s developers who decide what future browsers will support by writing (or not writing) JavaScript libraries. HTML5, too, was started by developers, and not by the vendors.

We wanted access to DOM elements by CSS selector. Browsers didn’t support this, so we wrote scripts. Then browser vendors woke up and added native support in the form of querySelectorAll.

iPhone apps introduced swipe interaction for switching between pages (states?). The browsers can’t do it, and people started to write scripts to emulate the behaviour. Any day now the browser vendors will come to the remarkable conclusion that there should be a CSS declaration for swipe transitions.

So new interaction models will show up in native apps first, and will be copied to a JavaScript library if they’re interesting for web developers. The fastest browsers won’t catch up until a year later, because they first want to review the functionality. It’s more like three or four years before all major browser vendors support it, but once that’s happened it works everywhere.

By building a native app you win room for experiment, but lose the reach a web app offers. That’s nothing new, really, but it’s important to note that the browser is designed to be somewhat behind the state of the art, and makes up for it by its reach.

There really is too much to list as this release is feature packed! Of course the most exciting being WebGL and hardware acceleration from our perspective.

Firefox 4 now has WebGL enabled by default. Based on the original 3-D Canvas work by Vladimir Vukićević, this is being

widely implemented in browsers. The WebGL spec is on the short path to a 1.0 release and we’re very excited to see this be used in the wild.

Hardware acceleration has finally arrived even though it should have been in nearly all platforms for web last decade, but we’ll take it.

Firefox 4 supports full hardware acceleration on Windows 7 and Windows Vista via a combination of D2D, DX9 and DX10. This allows us to accelerate everything from Canvas drawing to video rendering. Windows XP users will also enjoy hardware acceleration for many operations because we’re using our new Layers infrastructure along with DX9. And, of course, OSX users have excellent OpenGL support, so we’ve got that covered as well.

The javascript engine JaegerMonkey is comparably fast to SunSpider and V-8 javascript benchmarks and has support for EC5 javascript.

And you might have noticed that it’s really fast. This is the world’s first third-generation JavaScript engine, using Baseline JIT technology similar to engines found in other browsers and kicked up a level with the Tracing engine found in Firefox 3.6. As such, we’re competitive on benchmarks such as Sunspider and V8, but we’re also fast at a whole mess of things that we expect to see in the set of next-generation web applications, hence Kraken.

WebConsole looks like they are joining Chrome and Safari with built in inspection tools similar to Firebug, however Firebug still available.

Firefox 4 will include the Web Console. This is a new tool that will let you inspect a web page as it’s running, see network activity, see messages logged with console.log, see warnings for a page’s CSS, and a number of other things.

Note this that is something that we’ll be including with Firefox 4 directly. It’s not an add-on.

(Also Firebug will be ready for the final Firefox 4 release.)

Firefox 4 has other improvements like layering (in-memory retained layers), caching/scheduling improvements and lots of other performance enhancements.

2011 is looking like the year all this is coming together, at least for Chrome, Firefox, possibly Safari (need WebGL in main release) and IE is still the biggest problem to getting WebGL. At this point WebGL looks like it is still over a year out as it may not come to IE until IE10 or possibly never, the WebGL 1.0 spec is on the fast track though (don’t we all love Khronos? They have been amazing with OpenGL since they took over).  html5 is looking like it will be close to mainstream by the end of this year depending on the install rate of IE9 when released.

The world is waiting to see if Microsoft implements WebGL or tries the old DirectX/D2D only ways.  Nevertheless, getting a push for hardware acceleration and fast renders in 2d/3d is a very sweet direction.

Good news for the beginning of hardware accelerating the web, WebGL will now be part of the main Chrome releases not just a compile option for Chromium nightlies.

Google Chrome 9 enables WebGL support by default. “WebGL is a new web technology that brings hardware-accelerated 3D graphics to the browser without installing additional software” and it can be used to create cool applications like Google Body Browser, Field, Aquarium and more.

The update for Chrome 9 also sandboxes Flash, WebGL and plugins like extensions and tabs so that using them will be more secure and not crash the browser or the tab. Hopefully Safari has this soon, and then a few years from now IE may get it. Or they will put out their own DirectX web plugin so everyone has to write it twice like currently in game development. /sarcasm

The Web used to be so simple. Browser request goes to server, where you do some work, and return some HTML. Then we got Ajax and finally web apps could have some semblance of UI responsiveness. Now we have richer HTML5 technologies to change expectations of our users once again.

The Web is getting some new DPI love, and the new iPhone 4 display personifies this fact. The new display is fantastic for the consumer, and an opportunity for the design enlightened to build truly beautiful web sites. There is a big difference:

However, how do we as developers deal with this new world?

Aral Balkan has a nice post that goes into detail on the new opportunity and shares samples and ideas.

As with so many things on the Web, some of this has been thought of a loooong time ago. Dave Hyatt wrote about this back in 2006.

Walt Dickinson put together a guide to the retina display and using CSS3 media queries:

Aral explains that "in the Retina-specific CSS, he loads in 32x32 icons as background images and specifies their dimensions in CSS pixels as 16x16 using the background-size CSS property."

It is interesting to see a device pixel ratio used rather than specifying a DPI itself.

What else can be done to help folks in this new world?

Aral talks about how the browser could natively help via convention:

I'd like to suggest that browsers adopt the same naming convention that Cocoa Touch uses to find and load high-DPI versions of image and video assets. That is, if I embed an image using the following code…

PLAIN TEXT

HTML:

<img src="flower.jpg" alt="A beautiful rose"/>
 

… it should load in flower.jpg when the device-pixel-ratio is 1 but it should attempt to find an image called flower@2x.jpg at the same relative path if device-pixel-ratio is 2 (and so on, for higher pixel-ratios), falling back to the original graphic if it can't find a high-resolution version.

(And the same convention could be used to load video assets.)

Maybe there are server side techniques that could be put in place to automatically serve up the most optimized image for a given DPI. This would stop a bunch of 404s, but requires more work on the part of the server monkey.

This is good news for SVG and libraries like Raphael, who are well suited for scaling. When playing with an iPhone 4 it was amazing how quickly you noticed the bitmaps that were too low res... they stick out like a sore thumb. Expectations have changed.

What else can we do?

The Chrome and HTML DevRel team at Google have released a new portal, HTML5 Rocks, that packages together some of the great resources available on HTML5 and the renaissance of browsers.

Whether it be references on what you can do, to readiness to shims to get use features now.

Beyond the resources, there is the killer HTML5 Slide Presentation and interactive playground.

A lot of nice stuff, all in one place. This is the first release, and we are sure to see a lot of additions coming soon. What would you like to see?

The Chrome and HTML DevRel team at Google have released a new portal, HTML5 Rocks, that packages together some of the great resources available on HTML5 and the renaissance of browsers.

Whether it be references on what you can do, to readiness to shims to get use features now.

Beyond the resources, there is the killer HTML5 Slide Presentation and interactive playground.

A lot of nice stuff, all in one place. This is the first release, and we are sure to see a lot of additions coming soon. What would you like to see?

Some good news in the land of browsers. Firstly, the Chrome team has released a new beta that features impressive performance numbers to go along with HTML5 features that have all been baking in the developer channel.

First we have the performance. It is cool that they only compare with themselves:

Seeing V8 get faster is exciting for me personally. Not only does it mean Chrome gets faster, but I also get the advantage of a faster webOS and a faster node.js!

Then we get the HTML5 features that aren't hidden behind runtime flags:

Under the hood, today's release contains the goodness of some new HTML5 features, namely Geolocation APIs, App Cache, web sockets, and file drag-and-drop capabilities.

And in the global market share game, at least according to net applications, IE is below 60%:

This is great news, and I hope that we continue to see that pie spreeeead out nicely. A nice balance of IE, Firefox, Chrome, and others would be very nice to see indeed. The browsers are doing solid work right now. My Firefox nightly is starting to scream, and still is second to none in the "get it to do exactly what I want" category. It continues to be a fun 2010 :)