Google keeps tempting the tech community with new and exciting software. But, until they commit to stop recording private data about individual users of their products, everyone with an ounce of sense should boycott their products.
Until then, Google remains the biggest source of spyware on the planet.
Google plugs 3D hardware into Chrome
Summary
By building its O3D plug-in into Chrome, Google is moving towards faster web apps in its browser - and later in its operating system.
Topics
Departing significantly from what other browsers offer, Google has begun building its O3D plug-in for hardware-accelerated 3D graphics into its Chrome browser.
"The O3D team is working on getting O3D integrated into the Chromium build, and we're close to being able to complete our first step towards integration," said programmer Greg Spencer in a mailing list announcement Wednesday about Chromium, the open-source project that underlies Chrome itself. "I'll be making the Windows build of Chromium be dependent upon building O3D as part of the build process."
By helping to pave the way for high-powered Web-based games, the move furthers Google's ambition to speed the transformation of the Web from a static medium into a foundation for applications. Another piece of the work is Google Native Client, which is designed to let Web applications take advantage of a computer's native processing power.
The overall effort has taken on new importance with the announcement of Chrome OS, Google's Chrome-based operating system set to arrive on Netbooks in the second half of 2010. Chrome OS will use Linux under the covers, but the real foundation for Chrome OS applications is the Web, Google has said.
Native Client coming, too
Google plans to build Native Client into Chrome, too.
"We recognize that there is well-justified resistance to installing browser plug-ins. For this reason, we have a strong preference for delivering Native Client pre-installed or built into the browser, and we'll be focusing on that as our main strategy for delivering Native Client to users," said Brad Chen, engineering manager of the Google Native Client effort, in June.
Just offering the technologies is only a first step. Google must convince programmers to learn to use them and convince Web developers to embrace them. That's not simple, especially when few browsers can take advantage of them.
Chrome won't be the only browser to feature the acceleration features, though, because Google is working on plug-in versions, too. By building the technology into Chrome, Google could exert some pressure on others to support it.
Making Native Client and O3D into some kind of standard could help convince programmers the technologies are worth supporting and win over potential rivals. "The support of ratified standards (that Web developers) can use is something that we are extremely supportive of," said Amy Barzdukas, general manager for IE, in an earlier interview.
After years of near-dormancy, development of HTML, the language used to describe Web pages, has hit a feverish pace right now as browser makers try to make the Web into more of an applications platform.
Browser wars are back
Google added new fury to the browser wars when it introduced Chrome in September 2008. Chrome has attained a small but respectable market share of nearly 2 percent, according to research from Net Applications, but it has a long way to go expanding from the technophiles to the mainstream.
Chrome doesn't have the Internet Explorer or Safari advantage of being built into an operating system--though that could change over the years if Chrome OS manages to overcome its challenges and catch on widely. And Mozilla's Firefox took years to achieve its present market share of about 20 percent, making it the top alternative to IE and in widespread enough use that Web developers often choose to make sure their Web sites work with it.
Google has been spending a lot of time reproducing what other browsers already have--plug-ins, bookmark management, print preview, and any number of mundane but useful features. But Google also has been working on innovation, including more robust security and faster performance when running applications written in the JavaScript Web programming language.
Google has high hopes that it'll be able to match the performance of desktop applications with its technology.
"With O3D, we think we'll be able to enable high-quality games, the kind you're accustomed to seeing on consoles, as well as CAD (computer-aided design) applications," Chen said in a May speech. And regarding Native Client, "We want to be within single-digit percentages of what you can do with the best desktop native code," he said.
Google also is participating in a separate 3D Web graphics effort spearheaded by Mozilla and the Khronos Group.
This article was originally posted on CNET News.
Just In
You don't need to use google's chrome. There are other alternatives based on the chromium codebase. In fact, bare chromium will work. SRWare Iron is another great alternative that comes with built in ad-blocking.
I, for one, don't think google will ever stop collecting data or stop data mining, but their contribution to the chromium platform is fantastic for us.
I, for one, don't think google will ever stop collecting data or stop data mining, but their contribution to the chromium platform is fantastic for us.
Well, it's been tried.
Maybe not native to the browser, but as plugins.
VRML and later X3D have been available as plugins.
Java actually already supports it via Java3D.
There are occasional gaming websites that offer it via their own plugins.
The problem is, gamers haven't been picking up browser based games.
And by "gamers" and "games" I mean AAA games played by "core" gamers. Yes, I know about Flash games - they've been around for a long time now. But if you're talking about 3D, you're not talking about casual games anymore.
The big question is: What's the advantage?
Platform independence? Not really - OpenGL has been offering that since day one, and most games are written in C++, which has compilers for nearly every platform imaginable.
Automatic updates? Nope - online distribution platforms like Steam and Impulse already offer that, and many games have automatic updating code built in.
Online storage of player data? Nope - multiplayer games do that already, especially MMORPGs.
So what's the advantage?
All of the usual advantages that people claim for online apps are moot for games, because games already offer them.
The only thing you get with a browser based game is the browser chrome - and, frankly, most gamers think that's a waste. Why launch a browser application to launch your game instead of launching it directly from the OS?
There are many issues with heading in this direction with games:
Offline storage of game assets is a big issue: Games require a lot of 3D models, textures, and other various artwork. If you have to re-load all of that every time you open your game, you're in for a painful multi-hour wait.
Even games like WoW, which are perfectly capable of downloading content on the fly, keep gigabytes of data on the local machine.
In addition, most games use C++, and for a very good reason: Performance. C++ compilers can spend a lot more time optimizing because they don't have to worry about launching the application right away. You can get a lot of high performance code by spending more time optimizing it before you ship it.
In addition, the performance you get with a C++ compiler is predictable, while a JIT compiled language is not predictable: Performance can vary depending on whether or not it has optimized a section of code yet.
You don't want your game stuttering while a player is playing because the JIT compiler has reached a new section of code and needs to compile it. Or because it's a dynamic compiler and decided to further optimize a section of code that the game was using.
Another thing to consider: You can shove email and word processors into servers easily because they don't really require too much in the way of client side performance. One of the reasons why browsers work so well for web applications is because most web applications are just HTML slapped on top of a server side application.
But it's a whole different game for games
. Games are generally very heavily bound to both the GPU and the CPU, and obtain no benefit from being on a browser. You can't put them into a thin client setup like you can a word processor, and you gain no benefits at all from throwing them into a browser window.
For the best performance with the least lag, you need to be throwing those polygons and performing those AI and physics calculations on the client side.
If you try to throw them onto a server, here's what happens:
-Your costs skyrocket. The latest video cards are expensive, and you're buying one for every player hitting your server.
-Bandwidth becomes a tremendous problem. You're piping real time, full screen, often HIGHER than 1080p video to everybody.
-Either that, or you're piping huge amounts of art assets to the player. On the order of gigabytes, perhaps tens of gigabytes (I own games that are larger than 10 GB).
-Lag becomes a problem. You now have an extra network trip for the keyboard/mouse actions and the resulting video.
-And by "lag," I don't just mean bandwidth: I mean latency. Even at the speed of light, the time it takes to travel halfway around the world is well within human perception range. You're not going to solve that with bigger pipes or better technology.
-Your players are now playing "in a browser." Which is basically sitting there doing nothing. It doesn't give them any benefit.
Is it theoretically possible to do it? In some ways, yes. Runescape and some other games do it.
But every time you lose the cached copy of the applet, you have to wait for the game's basic code and assets to reload. In addition, if the game can't load new assets fast enough, you get lag spikes and/or parts of the map appear blank while the scenery is loading.
In addition - what is the browser doing during this time?
Well, it's doing nothing.
-Most gamers play in full screen. The browser chrome is gone.
-The game itself is likely just a plugin. The browser supplies a container to hold the plugin, but that's about it.
-I can guarantee that game devs are going to bypass pretty much everything in a browser to squeeze as much performance as they can out of it.
-If you think that future games are going to be this mess of scripting and markup languages that we have today for web applications - think again. It's not happening.
Basically, the browser really provides no services that are useful to a 3D game. 3D games don't use HTML, they don't use JavaScript, they don't use any of the common protocols, and they don't use any of the services that the browser provides. A browser really doesn't provide any benefit for a 3D game.
This *might* give us something like Google Earth in a browser - but I find it highly unlikely that the gaming community is going to use it much.
Maybe not native to the browser, but as plugins.
VRML and later X3D have been available as plugins.
Java actually already supports it via Java3D.
There are occasional gaming websites that offer it via their own plugins.
The problem is, gamers haven't been picking up browser based games.
And by "gamers" and "games" I mean AAA games played by "core" gamers. Yes, I know about Flash games - they've been around for a long time now. But if you're talking about 3D, you're not talking about casual games anymore.
The big question is: What's the advantage?
Platform independence? Not really - OpenGL has been offering that since day one, and most games are written in C++, which has compilers for nearly every platform imaginable.
Automatic updates? Nope - online distribution platforms like Steam and Impulse already offer that, and many games have automatic updating code built in.
Online storage of player data? Nope - multiplayer games do that already, especially MMORPGs.
So what's the advantage?
All of the usual advantages that people claim for online apps are moot for games, because games already offer them.
The only thing you get with a browser based game is the browser chrome - and, frankly, most gamers think that's a waste. Why launch a browser application to launch your game instead of launching it directly from the OS?
There are many issues with heading in this direction with games:
Offline storage of game assets is a big issue: Games require a lot of 3D models, textures, and other various artwork. If you have to re-load all of that every time you open your game, you're in for a painful multi-hour wait.
Even games like WoW, which are perfectly capable of downloading content on the fly, keep gigabytes of data on the local machine.
In addition, most games use C++, and for a very good reason: Performance. C++ compilers can spend a lot more time optimizing because they don't have to worry about launching the application right away. You can get a lot of high performance code by spending more time optimizing it before you ship it.
In addition, the performance you get with a C++ compiler is predictable, while a JIT compiled language is not predictable: Performance can vary depending on whether or not it has optimized a section of code yet.
You don't want your game stuttering while a player is playing because the JIT compiler has reached a new section of code and needs to compile it. Or because it's a dynamic compiler and decided to further optimize a section of code that the game was using.
Another thing to consider: You can shove email and word processors into servers easily because they don't really require too much in the way of client side performance. One of the reasons why browsers work so well for web applications is because most web applications are just HTML slapped on top of a server side application.
But it's a whole different game for games
. Games are generally very heavily bound to both the GPU and the CPU, and obtain no benefit from being on a browser. You can't put them into a thin client setup like you can a word processor, and you gain no benefits at all from throwing them into a browser window.For the best performance with the least lag, you need to be throwing those polygons and performing those AI and physics calculations on the client side.
If you try to throw them onto a server, here's what happens:
-Your costs skyrocket. The latest video cards are expensive, and you're buying one for every player hitting your server.
-Bandwidth becomes a tremendous problem. You're piping real time, full screen, often HIGHER than 1080p video to everybody.
-Either that, or you're piping huge amounts of art assets to the player. On the order of gigabytes, perhaps tens of gigabytes (I own games that are larger than 10 GB).
-Lag becomes a problem. You now have an extra network trip for the keyboard/mouse actions and the resulting video.
-And by "lag," I don't just mean bandwidth: I mean latency. Even at the speed of light, the time it takes to travel halfway around the world is well within human perception range. You're not going to solve that with bigger pipes or better technology.
-Your players are now playing "in a browser." Which is basically sitting there doing nothing. It doesn't give them any benefit.
Is it theoretically possible to do it? In some ways, yes. Runescape and some other games do it.
But every time you lose the cached copy of the applet, you have to wait for the game's basic code and assets to reload. In addition, if the game can't load new assets fast enough, you get lag spikes and/or parts of the map appear blank while the scenery is loading.
In addition - what is the browser doing during this time?
Well, it's doing nothing.
-Most gamers play in full screen. The browser chrome is gone.
-The game itself is likely just a plugin. The browser supplies a container to hold the plugin, but that's about it.
-I can guarantee that game devs are going to bypass pretty much everything in a browser to squeeze as much performance as they can out of it.
-If you think that future games are going to be this mess of scripting and markup languages that we have today for web applications - think again. It's not happening.
Basically, the browser really provides no services that are useful to a 3D game. 3D games don't use HTML, they don't use JavaScript, they don't use any of the common protocols, and they don't use any of the services that the browser provides. A browser really doesn't provide any benefit for a 3D game.
This *might* give us something like Google Earth in a browser - but I find it highly unlikely that the gaming community is going to use it much.
Take a look at http://quakelive.com/
It will show you that all the issues you mentioend
have been solved already, and also why running in
a browser is a good idea and what advantages it
has. You're suffering from a 1990s mindset.
It will show you that all the issues you mentioend
have been solved already, and also why running in
a browser is a good idea and what advantages it
has. You're suffering from a 1990s mindset.
My understanding of the Chrome OS is that it is a Linux kerneled OS that is browser centric. That does not exclude any of the things you are talking about whether it is Open GL or Direct X. You may want to think of it is a middle weight client. Not as thin as a browser, but not as fat and Windows, OS/X or Linux. Maybe more like a phone OS on steroids.
I'm not at all an advocate for any cloud OS, it
has it's place, but I'm sure there will always
be a market for full client side OS's. But with
a thin OS (such as chrome OS is supposed to be)
launching a game from a browser could put LESS
stress on a system as there are less processes
running in the background (or whatever
processes are called in linux world). The
number crunching a GPU does for graphics is the
same whether the data comes from within a
browser or from a game. The graphics engine
won't be written in javascript, it will be
written in optimized machine code. The biggest
slowdown I personally can think of will be in
areas such as AI that can possibly be written
in javascript. But the latest javascript
engines are pretty darn fast. (of course a
little difference in speed can turn into a BIG
difference with recursive logic or something)
and I've never read anything that suggests that
you can't cache your game on your computer so
you don't have to download it again. Browsers
have a cache, so that really only makes sense.
While opengl is crossplatform the rest of a
game isn't (unless your using something like
.NET, but then you hit a whole other set of
performance issues), most games are not written
for other platforms and can be extremely
finicky in emulators or a VM (as well as
further performance issues). Running games and
applications will sandbox the game from your
system adding a layer of security, much like a
VM, but with the added benefit of using trusted
optimized machine code (like O3D) without the
added layer of virtualization. Also we'll see a
whole new generation of "try before you buy"
software that is harder to hack and play
forever. (of course there is always a way, and
will probably become just as prevalent with a
little time). There are also a LOT of games
that are quite popular but do not need the
latest and greatest hardware to play (one that
comes to mind is world of goo!) such games
often become MORE popular as they have a wider
audience than just the ******** gamer. Such
games appeal to just about every demographic
from little kids to old grandmas. (example: the
popularity of "you don't know jack" form the
'90s, just a trivia game, but one of the best
selling games of it's time) and not everyone
ONLY plays the latest and greatest, two of the
games that I STILL play the most are
counterstrike and day of defeat and those are
what... 3-4 years old? They run perfectly fine
on my $800 laptop. And once such games are
designed they (in theory) will always be
compatible, so the older games will run on
cheaper hardware (such as netbooks). Which will
run games as good as a DS, PSP or an iPhone.
I've had quite a few hours of fun playing quake
1, duke nukem 3d and abes oddessy on a netbook.
I'm sure I will never put a thin OS on my
desktop or laptop, but on a netbook, what more
do you need? It won't replace existing OS's,
cloud OS's will never replace full featured
client side OS's, but it adds a fantastic
option for many devices.
SO THERE! :-P
has it's place, but I'm sure there will always
be a market for full client side OS's. But with
a thin OS (such as chrome OS is supposed to be)
launching a game from a browser could put LESS
stress on a system as there are less processes
running in the background (or whatever
processes are called in linux world). The
number crunching a GPU does for graphics is the
same whether the data comes from within a
browser or from a game. The graphics engine
won't be written in javascript, it will be
written in optimized machine code. The biggest
slowdown I personally can think of will be in
areas such as AI that can possibly be written
in javascript. But the latest javascript
engines are pretty darn fast. (of course a
little difference in speed can turn into a BIG
difference with recursive logic or something)
and I've never read anything that suggests that
you can't cache your game on your computer so
you don't have to download it again. Browsers
have a cache, so that really only makes sense.
While opengl is crossplatform the rest of a
game isn't (unless your using something like
.NET, but then you hit a whole other set of
performance issues), most games are not written
for other platforms and can be extremely
finicky in emulators or a VM (as well as
further performance issues). Running games and
applications will sandbox the game from your
system adding a layer of security, much like a
VM, but with the added benefit of using trusted
optimized machine code (like O3D) without the
added layer of virtualization. Also we'll see a
whole new generation of "try before you buy"
software that is harder to hack and play
forever. (of course there is always a way, and
will probably become just as prevalent with a
little time). There are also a LOT of games
that are quite popular but do not need the
latest and greatest hardware to play (one that
comes to mind is world of goo!) such games
often become MORE popular as they have a wider
audience than just the ******** gamer. Such
games appeal to just about every demographic
from little kids to old grandmas. (example: the
popularity of "you don't know jack" form the
'90s, just a trivia game, but one of the best
selling games of it's time) and not everyone
ONLY plays the latest and greatest, two of the
games that I STILL play the most are
counterstrike and day of defeat and those are
what... 3-4 years old? They run perfectly fine
on my $800 laptop. And once such games are
designed they (in theory) will always be
compatible, so the older games will run on
cheaper hardware (such as netbooks). Which will
run games as good as a DS, PSP or an iPhone.
I've had quite a few hours of fun playing quake
1, duke nukem 3d and abes oddessy on a netbook.
I'm sure I will never put a thin OS on my
desktop or laptop, but on a netbook, what more
do you need? It won't replace existing OS's,
cloud OS's will never replace full featured
client side OS's, but it adds a fantastic
option for many devices.
SO THERE! :-P
Let's hope Google has an RDP client on their OS so that they can run those "missing" Windows apps. While they are at it, it might be a good idea to have 3D acceleration on Direct X software too
In the meantime, we can always use ThinServer
http://www.aikotech.com/thinserver.htm
There are native Linux RDP clients. At this same moment I am at home on Linux, VPNing to work using an opensource Cisco compatible IPSEC VPN client vpnd and remoting using rdesktop to my Windows desktop.
Join the conversation!
The best of ZDNet, delivered
ZDNet Newsletters
Get the best of ZDNet delivered straight to your inbox
Vendor Showcase
Facebook Activity
