Chrome OS Switches To "Freon" Graphics Stack To Replace X11

[justmy2cents]

Unused RAM is wasted RAM

(partially joking of course)

nah. was my bad. i should've been more specific. although used/unused doesn't fly here, it's more like abused

[Lennie]

HTML5 as a base for apps? it's a "no" for me.
Java, Python, Ruby, C# - it's a "no" for me again.

I do nto want any heavy browser engines, any scripts, any garbage collectors on computers and mobile devices as a base for apps. That's primarily why Windows Phone, Android or FirefoxOS suck - they use havy stacks for developers, because they are simply too lazy to learn C++, Swift or something "closer" to the metal.

And believe me - modern C++ is a modern, high-level, partially declarative language. You just need to learn something beyond classes and pointers.

Actually, asm.js* is now already faster than native in certain cases, look at the top graph:

http://arewefastyet.com/#machine=28&view=breakdown&suite=asmjs-ubench

* remember asm.js is: C++ compiled to LLVM bytecode and transpiled to a Javascript subset. And then JIT-or AOT-compiled to native in the browser

Yes, it doesn't make a lot of sense, but the world doesn't make a lot of sense. Deal with it. :-)

[Lennie]

So, to me, the only fast, low level language that might be usable for such code is rust. But I'd still chose other languages like JavaScript over it for UI code all the time, because it's just very good at it.

Anyway, it's not the language that makes HTML slow, it's HTML itself. Because HTML & CSS still tries to be compatible with apps written in the very first days of HTML, rendering engines have to support a HUGE feature set, which makes rendering engines painfully slow, compared to other more primitive UI toolkits. HTML could be easily fixed by removing features that turned out to be bad & slow and making it more simple. If that would happen, you wouldn't notice a difference in performance compared to Qt and co. But it would be much safer.

Servo from Mozilla is looking pretty good, the new Rust-build browser engine seems to get a lot better performance than the old C++ engines:

https://www.youtube.com/watch?v=7q9vIMXSTzc

(obviously the reason isn't because C++ is slow, but because Mozilla started from scratch with a new engine which can take advantage of all the cores you have now)

[Luke]

Chrome OS good mostly as a source of machines not locked to Windoze

To me, Chrome OS has exactly one function: keeping Chromebooks on the market for those of us who trust neither Windows nor Google to install Linux on without any of that Secure Boot or Boot Guard crap. Google uses a hacked Coreboot under ChromeOS, and I hear that once put into "developer mode," theses machines can take upstream Coreboot and then any distro you want. If you don't want to screw with firmware, using the "developer mode" switch will let you boot any other distro at the penatly of an added 30 seconds boot time anyway. A lot easier than having to first pay for, then defeat Microsoft's boot-time "security."

All those people making Google accounts and selling their personal information to the highest bidder are at least subsidizing this alternative to dealing with Windows, at considerable price to themselves. Personally I refuse to have accounts with Google or with Facebook, and in fact have both servers blocked except through Tor, along with all their data-mining sharing widgets.

If most computer users thought this way, computer makers would produce for the resulting market, probably throwing up their hands about OS issues and selling machines with empty disks. Most machines would actually be cheaper, as presumably only part of the no longer paid "windows tax" would be pocketed by OEM's or stores.

[marcheu]

Seems to be really really tiny. There are only 24 files
common.mk dbus.h font.c input.c keysym.h main.c Makefile shl_pty.h splash.h term.h util.c video.c
dbus.c dbus_interface.h font.h input.h LICENSE main.h shl_pty.c splash.c term.c term.o.depends util.h video.h
all taking 372k, where the largest file is font.c at 208k, which appears to be a really simple font format for a terminal...

What you're looking at here is just a part of freon; it's frecon (short for "freon console"). It is a very small KMS-based console. It is kept very small for multiple reasons (needs to start quickly, needs to fit on our 4MB recovery image ramdisk...) which is why it doesn't have any bells and whistles (no fancy fonts, no keyboard layout support...).

...and reading the Google+ comment from one of the developers, he said it's not a display server...


I guess they're running chromium bare metal...

Yes we are, Chrome in Chrome OS does all its compositing by itself already (even with X11 builds), so we just removed the display server completely. If you want to draw a parallel with Wayland, parts of Chrome are sitting at the same level as Weston (on top of modeset + OpenGLES APIs).

[vadix]

Honestly, I've been hoping people could ditch GTK and Qt for a few years now in favor of HTML5 frontends. I know that's a crazy idea, but in the near future it may make a lot more sense than what we've been doing.

As much as I love standardization, I would hate to see HTML5 become the layout specification for everything. Also, there is no universally supported way to distribute/use compiled binaries via HTML5 in web browsers. I really do wish that pepper and pnacl were friendly enough to get implemented universally, but it doesn't seem that is the case. I think relying only on Javascript is holding the web back from its potential; though perhaps WebCL will enable some interesting performance capabilities once we actually see it around...

[scionicspectre]

It seems like a lot has happened since I opened that HTML5 vs widget toolkit can of worms, and I couldn't justly address those points without taking up a massive swathe of space. So, instead, I'll simply say that you've all made very good points, and it's not at all a simple proposition.

I will note that it's not an impossible goal to make HTML5 competitive with toolkits in the majority of ways you've all mentioned, and many people are working very hard to standardize the functionality that will make it feasible across platforms. GTK and Qt aren't going anywhere, and I don't think they should vanish into the wind even when web technologies have reached parity.

[scionicspectre]

When Rust gets Qt bindings or someone with balls uses Qt as a reference to implement a Rust native toolkit of equal class that has native QML support, we will have something marvelous.

Though you should not be afraid of Qt because of C++ - you can actually write your own QML applications that never use C++ at all, and are just run through the JIT on your machine (usually qmlscene, plasma has its own version of it though). Problem is that it is then restricted to what JS can do, ie, no local disk access.

Yes, I think the main reason I'd rather get used to C++ is just to do things the 'right' way, or the traditional way that would enable me to contribute in a more meaningful way. I'm no stranger to C++ though, I just avoid it when I can. If I spent a good month with it I'm sure I'd have a greater appreciation for it. Even still, I think C++ has plenty of competition even among high-performance object-oriented languages, lately (like Rust).

Even if you plan to use C++, I think using solely QML for a prototype is still a smart idea. I can't even begin to fathom how awesome a 'Rusty Qt' would be.

[liam]

There'd be no point, Weston is a display server, and they don't need one. They have only one app running, the browser, and that can run directly sitting on the drm layer.

Yup. That's exactly how fxos works.
Gecko, our rather a part of gecko (I don't recall what it's called) sits right on top of the frame buffer (it's more complicated than this, but the short story is gecko is the system compositor).

[liam]

UI in Qt can be declared with QML which is a markup language.
Style in GTK are declared in a CSS dialect.

Firefox is a incoherent mess with no native-look-and-feel and where every app looks alien. It has no consistency.

Application user interfaces in HTML should be easier to do right now with CSS flexbox (which is like of like hgroup and vgroup in GTK).

Fxos absolutely has assets. I think they use the term Blocks for their asset library.