Presentation and Inquire

Erik De Rijcke derijcke.erik at
Wed Apr 1 07:39:39 UTC 2020


I'm the author of Greenfield, and just like you and a lot of people, I too
wanted a machine I could access any time, any place, anywhere.

First some technical considerations you have to keep in mind depending on
which solution you prefer:
- Remote virtual screen (VNC, RDP, Citrix, ...). This is the easiest and
most widespread solution. The big advantage is that it's simple (just send
a single buffer of pixel over the network), and the actual visual state of
applications lives remotely. Meaning that if you disconnect, you can easily
reconnect and everything looks and works as it was.
- Remote application with local screen. This is harder to do depending on
how you visualize your applications locally. You can use an existing
locally running Wayland compositor to do the job ( solution) or implement an
entire Wayland compositor in the browser ( solution). A big drawback is that a
network disconnect will potentially corrupt or completely lose the
client/server state. Making any applications you were using useless. A big
advantage is that you are no longer bound to a single server and you can
basically scale your 'cloud desktop' as big as you want.

About writing a compositor in the browser, keep in mind that you can't
simply port Gnome to the browser, although it's theoretically possible to
recreate it at some leve given enough time (like all things software). With
Greenfield however, I started with using existing browser paradigms as that
meant I could use existing browser libraries and widgets. Having a Wayland
compositor running in the browser also opens up an entirely new class of
applications. Those that run directly in the browser itself. More info

As for performance considerations, neither solutions (remote screen vs
local screen) is better, as a full-screen application still covers the
whole screen anyway. What matters is the technique used to send pixel
updates, so far with what I've tested, HW accelerated H264 works best as it
has far superior compression than jpeg, has build in delta update
mechanism, has near universal HW encoding support and is still simple
enough to decode/encode fast when HW acceleration is missing. So if you
just want Gnome in the browser with good performance, search for an HTML5
remote screen solution that uses h264. Keep in mind though, HW accelerated
H264 in the cloud requires a GPU and the monthly price of those is
absolutely insane for that it really offers.

If you or anyone else has more interest in Greenfield, you're of course
always welcome to reach out to me.

best regards,


Op di 31 mrt. 2020 om 23:57 schreef Jean-Francois Dagenais <
jeff.dagenais at>:

> > On Mar 31, 2020, at 11:29, Matías Emanuel Denda Serrano <
> matutetandil at> wrote:
> >
> > Hi, my name is Matias, I'm a Systems Engineer, I've never developed nor
> helped developing something similar to this, but I'd like to start now.
> >
> > Here is the deal, I'm a developer, and on my daily basis I use my
> laptop, with time it gets obsolete and I have to change it (you may
> understand the situation perfectly). In order to be hardware independent,
> most of my apps are cloud-based, BUT there are some that don't, for
> instance, the IDE, chat, general apps, etc. (Also, when I travel I have to
> go with my laptop, and someone can steal it, it could be damaged, etc.)
> >
> > So, my idea was simple, I get a cloud server, I install my favorite
> Linux DIstro a Web Desktop Environment, and I access that machine for any
> place in the world with a Web Browser... My surprise was: "There is No Web
> Desktop Environment" or at least I couldn't find anything, probably because
> no one thinks a server the way I think a server.
> >
> > Summarizing, I'd like to develop and here is where I need your help or
> starting point, something that lets me render the "screen" within a
> browser. I'm VERY open to suggestions but basically my vision is to open a
> browser enter to, I will be asked for my username and
> password, and after the validation, I'll see the SAME Desktop Environment
> that the server has. For Instance, if I installed GNOME, then I will see
> GNOME (of course if Gnome supports Wayland).
> >
> > Btw, using VNC, is not an option, it is very slow and is not what I
> want. My idea is the browser to be the screen so I can minimize the traffic
> to the minimum. Also, I don't care about moving files from the machine
> where the browser is open.
> Hi,
> I've been really interested by this over the years. I agree with the
> philosophy entirely.
> Right now I have started using the remote SSH component in Visual Studio
> Code. It allows me to run the front-end on my local laptop, but he backend
> is my linux box at the office. Works well for the IDE itself, but there are
> always GUI tools that I still need and don't play well with remoting. X2go
> client/server works ok, but it is X11. For Wayland, a full desktop is being
> worked on by the gnome folks and others. But as far as I understand it, it
> is a remote screen. That is, there is a real picture rendered on the
> server, and this picture is sent remotely to a client as well.
> But a lot of things are happening, so one must keep looking.
> How we can use X11 through an SSH pipe is awesome, on paper. It is easy to
> run an X server instance on mac (XQuartz) or windows (MobaXTerm, cygwin,
> XMing, etc), then single windows or full desktop sessions. In practice,
> different story. It works well some of the time only. It highly dependant
> on the connection latency and on each application.
> Some work is ongoing to recreate this for wayland. But so far, it requires
> wayland on each side. Right now, this means linux on both sides as far as I
> know.
> For your web case, take a look at
> I have also just found this, not tried it or anything:
> Good luck!
> _______________________________________________
> wayland-devel mailing list
> wayland-devel at
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the wayland-devel mailing list