Wayland "desktop" port

335 views
Skip to first unread message

Rob Bradford

unread,
Nov 16, 2011, 1:48:25 PM11/16/11
to Chromium-dev
Hi,

I'm trying to work out the what direction a "desktop" port of Chromium
to Wayland should take. By desktop I mean a standalone browser that's
currently sitting on GTK/X11. Wayland is a display server architecture
that can be used to replace the X stack - it's still early days but
getting an application like Chromium working is a good test and also
helps us with some of the chicken and egg problems that you face with
a new technology.

Options:

A GTK on Wayland port - substituting any X11'isms with Wayland code
and fixing and improving GTK's Wayland support to enable this.

A pure views based approach - where there is a NativeWidgetWayland
implementation to back the views - a lot of this code was already
implemented by Daniel Nicoara.

Or does it make sense to go with the Aura port that Mandeep is
pursuing - is that applicable for a standalone desktop browser?

Any feedback would be much appreciated and apologies if I haven't got
my terminology quite right :-)

Cheers,

Rob
--
Intel Open Source Technology Centre

Elliot Glaysher (Chromium)

unread,
Nov 16, 2011, 2:21:23 PM11/16/11
to robert....@intel.com, Chromium-dev
On Wed, Nov 16, 2011 at 10:48 AM, Rob Bradford
<robert....@intel.com> wrote:
> Hi,
>
> I'm trying to work out the what direction a "desktop" port of Chromium
> to Wayland should take. By desktop I mean a standalone browser that's
> currently sitting on GTK/X11. Wayland is a display server architecture
> that can be used to replace the X stack - it's still early days but
> getting an application like Chromium working is a good test and also
> helps us with some of the chicken and egg problems that you face with
> a new technology.

That depends on what your goals are.

> A GTK on Wayland port - substituting any X11'isms with Wayland code
> and fixing and improving GTK's Wayland support to enable this.

If you're goal is to integrate into the current Linux desktop
(meaning: GNOME, Unity, XFCE, KDE, etc.), this is the obvious correct
choice. This requires quite a bit of porting though. We still compile
against GTK+ 2.18 because it's the latest GTK shipped in one of the
RHEL distributions (correct me if I'm wrong; I might be a version
off).

If you want to look at some of our X11isms, look at
content/browser/renderer_host/backing_store_gtk.cc (it's mostly X11
code, but is only used by the gtk port). You'll notice we do a bunch
of stuff with XShmCreatePixmap and XShmCreateImage. I also added some
X11 extension using code last week (it's the part of that file that
tests and opportunistically uses an XSyncExtension alarm to queue up a
bunch of drawing commands and have our alarm fired when done instead
of blocking our UI loop with an XSync()). There's also a bunch of
stuff in media/ that directly uses XRender that I have no idea about.

IIUC, wayland support won't be backported to GTK2; so we would first
need to do that porting. We break a lot of GSEALs. We also do a
surprising amount of stuff at the GDK level, and we can't start this
porting on trunk because the version of GTK we target is so old, it
doesn't have accessors for a bunch of the things we break GSEALs for.
Lots of unknowns here.

Also, flash is still linked with gtk2 and thus X11. We might be able
to get around that with some sort of nspluginwrapper like thing that
also proxies X11 calls, but ick!

> A pure views based approach - where there is a NativeWidgetWayland
> implementation to back the views - a lot of this code was already
> implemented by Daniel Nicoara.

I don't actually know what the plans are regarding the view world, I
mainly work on the GTK port. That said, the chromeos people are hard
at work removing GTK from views (though still depending on glib) and I
would expect that this configuration could work for you if you don't
care about the browser integrating with the desktop (theme stuff,
various gnome/xkce/kde integration and I think even XDG style stuff
though I'm not sure).

> Or does it make sense to go with the Aura port that Mandeep is
> pursuing - is that applicable for a standalone desktop browser?

IIUC, Aura is the replacement window manager for chromeos. You may
want to use this *anyway* since the plan is to Composite ALL the
layers!, but its design goals are to be a desktop environment
replacement.

-- Elliot

Ben Goodger (Google)

unread,
Nov 16, 2011, 2:25:33 PM11/16/11
to e...@chromium.org, robert....@intel.com, Chromium-dev
On Wed, Nov 16, 2011 at 11:21 AM, Elliot Glaysher (Chromium) <e...@chromium.org> wrote:
I don't actually know what the plans are regarding the view world, I
mainly work on the GTK port. That said, the chromeos people are hard
at work removing GTK from views (though still depending on glib) and I
would expect that this configuration could work for you if you don't
care about the browser integrating with the desktop (theme stuff,
various gnome/xkce/kde integration and I think even XDG style stuff
though I'm not sure).

> Or does it make sense to go with the Aura port that Mandeep is
> pursuing - is that applicable for a standalone desktop browser?

IIUC, Aura is the replacement window manager for chromeos. You may
want to use this *anyway* since the plan is to Composite ALL the
layers!, but its design goals are to be a desktop environment
replacement.

A few notes:

I expect that given the Aura work, NativeWidgetWayland and Wayland support directly in views will be removed before too long. Any wayland porting would be done at the DesktopHost level. Right now DesktopHost has a X implementation.

One note: aura_shell is the replacement window manager and shell environment. aura itself is just a window and event type. There are some wm-sounding concepts at play (e.g. "Desktop") but these are tenuous. I hope to migrate Chrome-on-Windows to Aura at some point, even in the regular (non-WM) build. It will allow us to do some cool UI effects.

-Ben

Paweł Hajdan, Jr.

unread,
Nov 17, 2011, 2:47:42 AM11/17/11
to e...@chromium.org, robert....@intel.com, Chromium-dev
On Wed, Nov 16, 2011 at 20:21, Elliot Glaysher (Chromium) <e...@chromium.org> wrote:
We still compile
against GTK+ 2.18 because it's the latest GTK shipped in one of the
RHEL distributions (correct me if I'm wrong; I might be a version
off).

Note that the code can be compiled against a more recent version of GTK+, i.e. on my Gentoo system it's 2.24.5. It's still 2.x though.

Rob Bradford

unread,
Nov 17, 2011, 10:34:59 AM11/17/11
to Chromium-dev
On Nov 16, 7:21 pm, "Elliot Glaysher (Chromium)" <e...@chromium.org>
wrote:
> On Wed, Nov 16, 2011 at 10:48 AM, Rob Bradford

> > A GTK on Wayland port - substituting any X11'isms with Wayland code
> > and fixing and improving GTK's Wayland support to enable this.

> IIUC, wayland support won't be backported to GTK2; so we would first
> need to do that porting. We break a lot of GSEALs. We also do a
> surprising amount of stuff at the GDK level, and we can't start this
> porting on trunk because the version of GTK we target is so old, it
> doesn't have accessors for a bunch of the things we break GSEALs for.
> Lots of unknowns here.

As you say in http://crbug.com/79722 realistically porting to GTK3 is
a long way off. Do you think it's viable to take steps to enable
compiling against GTK 2.12 (the version you mention in that bug) and
also against 2.28 with the structs sealed. This would require creating
compatibility functions and macros to support the accessors and
mutators that were missing in the older versions of GTK.

Is this the right time to start this effort? Would you be willing to
review such change sets? Following that do you think it's possible to
enable gtk3 via a compile flag?

>
> Also, flash is still linked with gtk2 and thus X11. We might be able
> to get around that with some sort of nspluginwrapper like thing that
> also proxies X11 calls, but ick!

Yes, icky :-)

Rob Bradford

unread,
Nov 17, 2011, 11:37:06 AM11/17/11
to Chromium-dev
> A few notes:
>
> I expect that given the Aura work, NativeWidgetWayland and Wayland support
> directly in views will be removed before too long. Any wayland porting
> would be done at the DesktopHost level. Right now DesktopHost has a X
> implementation.
>
> One note: aura_shell is the replacement window manager and shell
> environment. aura itself is just a window and event type. There are some
> wm-sounding concepts at play (e.g. "Desktop") but these are tenuous. I hope
> to migrate Chrome-on-Windows to Aura at some point, even in the regular
> (non-WM) build. It will allow us to do some cool UI effects.

Ben,

Thanks for the clarification. It sounds like it's not a good idea for
me to continue looking at updating NativeWidgetWayland and co and
instead help out with the work that Mandeep is doing targeting Aura to
get a DesktopHost implementation for Wayland.

Elliot Glaysher (Chromium)

unread,
Nov 17, 2011, 2:06:29 PM11/17/11
to robert....@intel.com, Chromium-dev
On Thu, Nov 17, 2011 at 7:34 AM, Rob Bradford <robert....@intel.com> wrote:
> As you say in http://crbug.com/79722 realistically porting to GTK3 is
> a long way off. Do you think it's viable to take steps to enable
> compiling against GTK 2.12 (the version you mention in that bug) and
> also against 2.28 with the structs sealed. This would require creating
> compatibility functions and macros to support the accessors and
> mutators that were missing in the older versions of GTK.

Since that bug was open, I believe we now target 2.18.

> Is this the right time to start this effort? Would you be willing to
> review such change sets?

If you were to create some sort of compatibility header mirroring new
methods that did the equivalent of:

#if GTK_CHECK_VERSION(2,20,0)
inline int gtk_get_something(GtkWidget* something) {
return something->break_seal_for_something;
}
#endif

and start moving parts of our GTK code so it compiled with struct
seals, I'd be grateful!

There's a lot of work to just get through the preparation we can do
while on GTK2, but...

> Following that do you think it's possible to enable gtk3 via a compile flag?

I really doubt it. Things are going to be way more complicated than
that! Just taking a look at
http://developer.gnome.org/gtk3/3.3/gtk-migrating-2-to-3.html ,
chromium hits most of those points.

- Most widgets that can display to the screen connect to the expose
signal and would have to be ported to the new draw signal.
- Most widgets muck with the size-request/size-allocate.
- A quick grep shows we use GdkRegion, GdkPixmap, GdkColormap,
GdkDrawable, and GtkObject at least some places in our code. (We
mostly use cairo for our drawing though.)
- We use low level event filtering to do some of our X11 tricks.
- Not mentioned in that document, but parts of our gtk theme
integration code call low level draw commands to the theme engine.
Take a look at chrome/browser/ui/gtk/gtk_util.cc:DrawTextEntryBackground()
for an example. I'm not sure if this is a problem or not.

So yeah. Lots of work to do here. I was planning on not bothering with
any gtk3 porting work until the next Ubuntu LTS dropped (since I'm a
bit swamped with other linux work), but there's actually a lot that
someone interested could do now to make the porting effort go quicker.

As a few hints, don't bother with any gtk code under ui/views/ or
chrome/browser/chromeos/. That code is chromeos/views specific should
be going away Real Soon Now.

-- Elliot

Elliot Glaysher (Chromium)

unread,
Nov 21, 2011, 7:00:06 PM11/21/11
to robert....@intel.com, Chromium-dev
On Thu, Nov 17, 2011 at 11:06 AM, Elliot Glaysher (Chromium)
<e...@chromium.org> wrote:
> On Thu, Nov 17, 2011 at 7:34 AM, Rob Bradford <robert....@intel.com> wrote:
>> Is this the right time to start this effort? Would you be willing to
>> review such change sets?

FYI:

http://codereview.chromium.org/8588068/ - Start of a compatibility header
http://codereview.chromium.org/8586044/ - Don't include single headers.

-- Elliot

Reply all
Reply to author
Forward
0 new messages