Java Bindings Come To Wayland For Android

[runeks]

I have no basis to judge whether Wayland is a good standard, but I'm hoping for convergence between the various Linux display servers. It would be cool to be able to use the same drivers for Linux, Android and Chrome OS, for example. If Android adopts Wayland, drivers won't be a problem, GPU vendors will be falling over each other offering Wayland compatibility. Would be nice if some of that fruit could fall off on Linux. Om nom nom nom.

[V!NCENT]

What's maybe also worth mentioning, is that Wayland works in multi-seat, for local server-client setups, and now a common large distance networking API, being HTMLv5, can do remote applications, which works on almost any OS, on any platform, even natively on Windows Internet Explorer, without requiring X.org.

The only thing you can't do with Wayland is playing Doom3 out of the box, but seriously, why the hell would you want that?

[Koorac]

Adding thru-JNI costs to native apps on Android will guarantee they're always second-class (ref Firefox OS's discussion vs Android). A common base penalizes either app type the least.

JNI only adds a few clock cycles to every call. On my machine it was like 5-10 nanoseconds.
So if your function call takes 1millisecond without JNI, it will take 1,000005 milliseconds with JNI.
IMO this is negligible overhead. Unless of course you are calling very short running JNI functions (a few nanoseconds) in a tight loop.
But if that is being done, your are most certainly doing it VERY WRONG

[snadrus]

Better software = fewer wasteful layers.

Wayland's lighter & built with more in mind.

versus GTK on Android:

• Wayland's worse for porting apps to Android (short term)
• Wayland's better if picked-up by Android (medium term)
• Wayland's best on non-Java Linux phones (long term) which could be tested soon in partial-Android environments

Adding thru-JNI costs to native apps on Android will guarantee they're always second-class (ref Firefox OS's discussion vs Android). A common base penalizes either app type the least.

[V!NCENT]

Why don't they just use the Android display server on Linux distributions instead of X.org or Wayland?

Why create Wayland when there is some display server on Android?
I don't think Android uses X.org, it probably has its own display server.

As far as I understand it, X.org suffering from a split personality disorder:
1. It has the classic, client-server framebuffer magic, and on the other end;
2. To modernize the Linux desktop with compoziting and whatnot, X turns more to local rendering code paths.

Wayland basically cuts the X.org architecture from the old framebuffer networking down to what X.org itself is build on, and puts a modern window management sauce on top.

If Wayland is then ported to Android, which is a good use case for stripped down, modern and local rendering, it also uses the modern Linux drivers. That means that if it turns out to work well with Android apps, things like the MK2 Android can be appear on small, yet common hardware devices, so for example you could carry a more standard Linuxy home theatre PC in your pocket and still make use from Android apps.

TL;DR: clean, standard Linux kernel implementations, thus less fragmentation between 'desktop Linux' and Android Linux.

[Ancurio]

But it would be more useful to add a Flinger/skia backend for GTK than trying to replace the whole android stack.
I'd rather see the linux desktop and android converge more for more compatibility (for thinks like ubuntu on android). As much as I hate Windows 8, it's leading the way for platform integration.

That's definitely a cool idea. You can send your patches to the gtk devel ml =)

[smitty3268]

But it would be more useful to add a Flinger/skia backend for GTK than trying to replace the whole android stack.
I'd rather see the linux desktop and android converge more for more compatibility (for thinks like ubuntu on android). As much as I hate Windows 8, it's leading the way for platform integration.

You're missing the point.

Wayland is written for Linux. The point of this is to test it out on Android, to see how easy it is to port, to make sure there are no hidden surprises, etc.

Porting GTK to surfaceflinger doesn't help out Wayland at all, and there are tons of reasons linux distros don't want to just dump X for surfaceflinger.

[newwen]

Wayland wasn't created for Android. I think you're talking about the bindings.
And the reason they're being written for Android is, I guess,
to simply "test out wayland in as many waters as possible" to gauge it's versatility as a protocol.

But it would be more useful to add a Flinger/skia backend for GTK than trying to replace the whole android stack.
I'd rather see the linux desktop and android converge more for more compatibility (for thinks like ubuntu on android). As much as I hate Windows 8, it's leading the way for platform integration.

[Ancurio]

Why create Wayland when there is some display server on Android?

Wayland wasn't created for Android. I think you're talking about the bindings.
And the reason they're being written for Android is, I guess,
to simply "test out wayland in as many waters as possible" to gauge it's versatility as a protocol.

[mark45]

Why create Wayland when there is some display server on Android?

You see, it's because not everyone is a genius like you.
Besides Flinger, being developed for smartphones can easily be extended to.. other smartphones.
And it will even work well on desktops, just like an OS can be written in JavaScript and still work (well enough to be worth bragging about it).

Sarcasm aside, Android uses a lot of half-baked but good enough solutions (the audio and graphics stacks) which over time got improved that they seem decent enough for certain scenarios, but they can be better. Like ext2 has been improved up to ext4 and supports a lot of features like punch holes - but btrfs is still the future. Wayland is way better from the get go, more versatile and not designed with only smartphones in mind.