So they have a web browser for the sole purpose of setting up an GLES context for their UI? On a video game console? I guess that's what you do when you suddenly have 8GB of RAM, you piss it away on useless shit...
Why is this pissing away performance? A web browser isn't some luxury. It affords them flexibility with ease of development and being compatible with the entire www. I really don't see the old days of proprietary junky interfaces being superior, especially on hardware that is close to what a modern desktop PC is today.
Not to mention, my crappy phone runs Chrome. If it can do that, certainly a device that uses up to 100 watts, has 16x the ram, 100x the graphics/cpu can too without it being considered a drain.
I never said anything about performance? I specifically mentioned RAM. Although it is pissing away performance because WebGL is slower than running GLES directly, thanks to the sanitation of the GLES shaders that the browser does.
But this is still a proprietary, "junky" interface. If it's WebGL, it's still entirely custom, with entirely custom event handling, and entirely custom accessibility (or lack thereof), and entirely custom everything. If you are just using WebGL, which is what they said, then the browser is a massive chunk of dead weight that's doing jack shit. All the browser did is setup the EGL context, create a GLES context from that, and then handed it to you. This is basic hello world stuff, that's the entirety of the browser's involvement in this scenario.
The G+ comments seem to indicate that they're using the browser's event handling in some way.
Plus the browser runtime still gives you things even if you're going the pure-GL UI route: networking, a JSON parser, a database (Local Storage), cookies and session management, a (arguably awful) security model... how is the browser "dead weight"?
All those things are easily provided by libraries for every language with every API imaginable. The strength of a browser is HTML & CSS.
And I called it dead weight because we're talking client-side offline UI here, so things like cookies and session management are irrelevant. But the dead weight is going to come from the bulk of the browser code that is HTML/CSS parsing, webkit/blink, the graphics model that's not being used, font support that's not being used, etc... Those things you list are all really small pieces.
I strongly suspect the PS4's UI is neither truly client-side nor offline.
I don't disagree that there's a lot wasted but I'd probably have made the same trade-off given the circumstances.
The PS4's UI isn't particularly resource-constrained as far as I know and it's often easier to start with a familiar environment with everything and the kitchen sink than to start with nothing and hand-pick blocks along the way. Plus based on Sony's past in-house UI performance, the "glue libraries together from floor 0" approach wasn't working out for them.
So far the PS4's UI is getting good reviews and is generally described as "responsive" so it sounds like they didn't really lose - in a modern device where you'll end up porting a browser anyway I don't see why using it for UI is such a sin.
> I really don't see the old days of proprietary junky interfaces being superior, especially on hardware that is close to what a modern desktop PC is today.
As a cynic, I would say web apps are all about proprietary junky interfaces instead of using my platforms standard GUI. Reminds me a bit of the VB6 days where every program used to define its own true button color... (except the modern web apps look a lot nicer, of course).
Counter-argument: the PS4's desktop is the one place where performance least matters. But they would like to add new UX features there, over time, with less dev effort. Especially basic UI content. That can be fetched remotely or locally, relatively seamlessly. Which is what browsers already do well.
It bothers me how little people care about responsive UI. I haven't used a PS4 yet, so this is more just a general comment than a criticism of the decision - but the PS3 is a bit of a clunker in its cross-media bar. There are spinning placeholders for a couple of seconds every time the icons load. It doesn't exactly scream raw power - why aren't devs embarrassed by these things?
FWIW, Ars' follow-up review of the PS4 talks about how there's still loading indicators in the main menu UI's, which should not happen IMO when you're essentially talking about icons and you have 8GB of RAM to work with.
The issue with the PS3's UI is that it's seen a marked increase in complexity since the initial release, coupled with less resource access. As it stands the PS3's XMB has access to about 80mb of RAM, the rest is reserved for games. Also everything I've heard about the PS4 makes it sound like the UI is incredibly fast and responsive.
He's right, though. On the PS4 desktop, you're not having 10s of thousands of particles that interact with each other being rendered at 60fps. You're not going through 100 passes with different shaders making the perfect experience.
You're having maybe 1000 particles or a 50,000 polygons. Much lighter weight. It doesn't /need/ the performance that a game does.
When the PS3 isn't running anything, the icons don't spin or need to load in. When in a game or app, however, they do. Why? Because the majority of CPU and memory is reserved by the game; the icons will not be in memory; you have to async load them and the game might be using some streaming resources.
Wait, why doesn't performance matter on the desktop? What happens when you hit the PS4 button (or whatever it is) in a game to bring up the UI overlay? What happens when you're in the desktop itself, panning around? What happens when you install updates? Do we have to sit through flickering screens as update after update is installed?!
Interface performance is really fucking important, and I sure hope people like Sony and Microsoft care when it comes to their consoles.
People like EA and the notoriously terrible Battlefield* interfaces obviously do not care. (The original Battlefield 1942 would switch from your native resolution and refresh rate and color depth and put the screen in 800x600 16bit 60hz every single time you hit the escape button.)
The performance of the desktop on the PS3 and PS4 is less important to the gamer than the performance of the games, also known as the primary purpose of the device.
However, that doesn't mean that it is unimportant.
> the PS4's desktop is the one place where performance least matters
Performance in general still matters a lot on the PS desktop. Case in point, my PS3, which takes a godawful amount of time to load all the screen icons.
It's not like any of that is difficult to do when your ecosystem is closed and you are the only one in control of it regardless of how you decide to execute it.
And (memory) performance is of critical importance if the PS4 supports multitasking such as the Xbox One does (don't know if it does).
They could still use JS and not use WebGL. WebGL is just GLES in a web browser. Slower than GLES running natively thanks to sandboxing overhead, for what it's worth. But I was more talking about the RAM overhead of using the browser just to create a window to render GLES into. You can easily achieve the same thing with EGL or SDL or whatever the PS4 natively provides to games. It's trivial to setup a GLES context.
Is there any more public information available on this? I know the PS3 used a highly custom API that was nontheless based on OpenGL ES (and added stuff that was missing like shaders), it seems like with more standard hardware and the more mature OpenGL ES standards available today, they'd stick with something more standards-compatible.
The PS3's API (LibGCM) had nothing to do with OpenGL. What Sony did however was provide an OpenGL ES 1.1+extensions implementation on top of the low level API. You can probably count on one hand the number of games that made use of it because it was too slow.
If they're using nothing but a WebGL context filled with custom code for text, layout, etc. then you have a fair point. I doubt that's the case, though. It seems likely that they're taking advantage of HTML/CSS on top of whatever WebGL parts they're using, allowing system UI work to be done by more general web design people rather than involving lower-level developers just to implement a new kind of dialog.
But if you are already bundling the browser, is it really a penalty to utilize it, especially since both the ps and xbox reserve space for the UI thread?
WebGL might be less performant but honestly, for a menu system it's plenty fast, so what's the big deal here? Honest question.
You assume the renderer they're using uses a large chunk of RAM. You assume they use exactly the same browser for the home interface as the normal web browsing. You assume that they're keeping the home interface in memory (and wasting resources) when you're playing a game.
I'm going to go out on a limb here and guess that you're not a game console developer. It's really not as simple as you're trying to make it out to be.
Platform has a web browser anyways. Web technologies are brilliant for laying out user interfaces.
Complain about it being useless shit.
Where have all of these cynical people come from today? Every discussion I've wandered into today has had a good showing of judgmental, know-better, seemingly angry people.
The difference is the UI runs continuously and is RAM that a game cannot use. The web browser, by contrast, does not. It stops running when you leave it. Or it could, anyway, if it wasn't also being used as a GL container for the UI.
Not to mention, my crappy phone runs Chrome. If it can do that, certainly a device that uses up to 100 watts, has 16x the ram, 100x the graphics/cpu can too without it being considered a drain.