Platform/GFX/GTK3: Difference between revisions
(Created page with "= Motivation = * GTK3 themes either don't or can't implement a GTK2 equivalent and distributions are using these GTK3 themes and so Firefox looks different. * New toolkit fe...") |
(→Cairo: cairo is not the likely Gecko drawing engine) |
||
| Line 32: | Line 32: | ||
= Cairo = | = Cairo = | ||
The GTK3 port is currently designed to use system cairo for Gecko drawing. Eventually, Gecko will probably use a different graphics system, but GTK themes will still need a system cairo context to draw. This will require a gfxCairoNativeRenderer or similar (c.f. [http://mxr.mozilla.org/mozilla-central/source/gfx/thebes/gfxXlibNativeRenderer.cpp]) to create a system-cairo context around a surface with appropriate clipping. | |||
= Builds and Tests = | = Builds and Tests = | ||
We need GTK3 installed on build and test machines, and to decide whether to ship GTK2 or GTK3 ports or both. | We need GTK3 installed on build and test machines, and to decide whether to ship GTK2 or GTK3 ports or both. | ||
Revision as of 03:23, 27 November 2013
Motivation
- GTK3 themes either don't or can't implement a GTK2 equivalent and distributions are using these GTK3 themes and so Firefox looks different.
- New toolkit features are added to GTK3 but rarely ported to GTK2. This includes support for input events such as touch events and Wayland.
What needs to be done
bug 627699 tracks some of the major code changes required. There are also annotations in the code where the port is not complete: [1] [2]
Plugins
Plugins use GTK2. GTK libraries do not version symbols and so if a GTK2 plugin is loaded into a process that already has GTK3 libaries loaded for global relocations, then symbol relocation for the plugin, even loaded with RTLD_LOCAL, will find the GTK3 symbols first (see man 3p dlopen). GTK2 and GTK3 also use the same names for different GObject types, so no GTK2 functions may run, even using RTLD_LOCAL, in a process also using GTK3.
Therefore a plugin-container executable needs to be built in a way that does not pull in GTK3.
The biggest issue is how to adjust the build system to do this in a maintainable manner, while still building the browser process with GTK3. gtest has a similar need to build multiple libxuls with different sets of source files ([3]). A GTK2 plugin-container has the additional requirement of having to compile the same source file with different preprocessor defines.
An ideal solution would not include all of Gecko in the plugin-container but only what is necessary. This includes mfbt, xpcom, ipc/chromium, parts of gfx, and dom/plugins/ipc.
Currently, plugin mimetypes are read from the browser process. This occasionally needs to happen for all plugins to create a database for determining which, if any, plugin is used for which mimetypes. Perhaps we could get lucky with RTLD_LOCAL dlopen if the plugin runs no functions and has no static constructors that use GTK/GDK, and GTK has no constructors, but this is delicate at best. A better approach is to read mimetypes from the plugin process and shut down these processes when done.
Cairo
The GTK3 port is currently designed to use system cairo for Gecko drawing. Eventually, Gecko will probably use a different graphics system, but GTK themes will still need a system cairo context to draw. This will require a gfxCairoNativeRenderer or similar (c.f. [4]) to create a system-cairo context around a surface with appropriate clipping.
Builds and Tests
We need GTK3 installed on build and test machines, and to decide whether to ship GTK2 or GTK3 ports or both.