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

[droidhacker]

What is the relationship between "Freon" and "Surfaceflinger"?

[droidhacker]

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.

Wow, what a thoroughly uninformed rant....

UI is inherently stupid. It takes some kind of a markup language to deal with that effectively. Android's use of Java is only skin deep, you write your UI in XML, you glue it together with a box and pretty buttons written in Java, OR you skip right into native code. You do your heavy lifting in C/C++. GC is only relevant for monkey coders. Keep track of and reuse references and you never have orphaned objects and never crippled by the GC.

Object a = new Object();
a = new Object();

When 'a' is assigned its second new Object, the first reference is orphaned and GC hits to clean it up.

OR

Object a = new Object();
a.reset();

Now the original Object is preserved, but its values are reset. No orpaned Object, no crippling GC.


And if you're concerned about monkey coders not taking care of their Objects, remember that those monkey coders can be a whole hell of a lot more destructive in C or C++, because there they will generate memory leaks that will make life TRULY miserable, rather than being able to have GC take care of them automatically.


So what I am saying; everything is some kind of a compromise, but Android does NOT limit you to a single compromise. It allows good developers to write good software, while protecting the user from BAD developers.

[robclark]

Someone on the Wayland IRC said it appears to be a small wrapper for the Direct Rendering Manager, and I have to agree... ...it appears that there is no client server abilities in this at all

...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...

yup, it's basically the chromium gpu process running on bare metal.

Why not fork Weston ? It's light as hell, eats almost no CPU. Loads in max 2s.

basically in the CrOS architecture, since they have the dedicated gpu process which runs fullscreen, there was no need for any sort of display server (x11/wayland/mir).

No idea how that effects crouton.. although for folks putting a few linux distron on their chromebooks, this should not change anything. Unlike android, with freon CrOS is still using a normal linux driver stack: drm/kms, and mesa/gbm (at least for devices w/ open source graphics drivers)

jfwiw, freon has been in the CrOS trees for a while now.. I was playing with it on an ifc6410 (reptile board) with freedreno a few months ago ;-)

[mr_tawan]

I think everything has its own uses. ChromeOS is actually quite good for some kind of uses as well (as they are quite popular in the education world I think).

Also I think it's not 'everything' that has to be a native application. Sometime performance is not really that matters. Those business people always prefer their efficiency (eg. how can they get jobs done), over the application performance (of course the most important thing is the correctness of the output). And it is actually a valid point.

Don't get me wrong, I always love C++, and I've been making a living with it for a decade now .

[VanCoding]

I'm i the only one...

...that thinks that writing user interfaces in C++ is a stupid idea?

Yes, C++ is fast & a perfect fit for low-level things that need to be fast. It's good at exposing APIs to higher level code.
But I cannot understand how one really can think that it makes sense to write everything in C++, even high level stuff like UIs.
C++ has serious problems with being memory safe. It just must not happen that one can fuck up the whole program with UI code.
Finding memory leaks in UI code is hard. Finding them in low-level code isn't, because unit tests are much easier to build for it.
Also, UI code usually makes heavy use of circular references. If you have code that needs circular references, use a language with a garbage collector! It's not only easier to deal with, it also is faster and results in much more expressive code. In UI code, you should not be dealing with memory.

Another aspect is security. Do you really want to introduce security holes in your applications UI code? It just happens, no matter how a good programmer you are.

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.

In qeneral, I don't like being forced to use a specific markup language for a UI toolkit. It should not be built right into the toolkit. Not for the web/DOM, not for QT. Also, there should not be any standard controls or standard designs built into the toolkit. In my opinion this should all be optional & available through third party libraries, so that developers have the most possible freedom.

Having one UI toolkit that isn't opinionated as much as HTML/DOM or Qt and would allow the developer to do everything that's currently possible in those frameworks by just using a library would truly be a dream

[Passso]

That and I'd love to chuck keyboards every time I get an off by one pixel alignment problem or some other crap in CSS, because fuck CSS.

To be more accurate I'd love to chucknorris keyboards in this case. Now that the platforms number have explosed (pc, tablet, qhd, mobile, and multiple browsers for each...) CSS is a mess. Try the ZOOM and you get another bonus multiplier!

I used to like the ide of a WebOs but I do not trust Google anymore. Fed up being "big brothered".
Add to this it contradict the single point of failure rule far too much, I keep my own littl' server with a backup.

Concerning this Freon, they made it so fast... So many engineers they have

[JS987]

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.

HTML5 applications would need about 10 times higher single threaded CPU performance and 10 times more RAM, which means 40 GHz CPU and 128 GB RAM.

[sykobee]

Front ends are just that - front ends. They should be concerned with UX, not the meat of the work. They often work on a client machine when the workload executes elsewhere.

I have no issue with a local app that presents its UI in the browser. It's good separation of concerns, allows the app's interface to be exposed at the API level rather than the UI level, and allows other front ends to be developed easily should you want to (e.g., develop KDE Plasma plugin).

Of course there are exceptions, but those exceptions are mostly front-end heavy applications, i.e., the core of the application is in presenting and managing front end aspects - e.g., CAD editing, movie editing, ...

I used to think this was a really cranky way to do things, but for many apps it's fine. A core app that does the work (e.g., a torrent engine that's always running) and a front-end that is separate for when you want to see/change what's going on.

[Passso]

HTML5 applications would need about 10 times higher single threaded CPU performance and 10 times more RAM, which means 40 GHz CPU and 128 GB RAM.

You mean Assassin's creed Unity will not land on ChromeOS? Who cares, this thing is intented for surf and watch videos of cats falling.

[zanny]

I guess I just need to get over my addiction to Javascript, Python, Vala, and C and come to grips with C++ some day. It just makes me uncomfortable because it feels like such a fundamental hack... wait a second.

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.