maemo.org Bugzilla – Bug 952
maemo-launcher gtk booster broken with gtk+ 2.10
Last modified: 2008-12-06 16:52:44 UTC
You need to
before you can comment on or make changes to this bug.
When run with gtk+ 2.10 maemo-launcher causes breakage in most, if not all,
launched applications. This includes input methods and maemo-af-desktop which
renders the whole development environment / device unusable.
There is an easy workaround (removing --booster gtk from
/etc/init.d/maemo-launcher) and we can make a suitable maemo-launcher version
available together with gtk package, so this is not urgent.
The reason for the crash is that maemo-launcher abuses knowledge about gtk
internals which changed from 2.6 to 2.10. Most likely this is related to the
change from pango/xft to pango/cairo, however my attempt to comment out just
that part of code didn't help. We need to go through all the initializations
maemo-launcher does one by one :-/
Actually the reason for the crashes is that maemo-gtk-2-6 doesn't clean up
stuff on display close (in fact it's completely broken). In upstream
2.10 most of this stuff is fixed, so the launcher has no chance of caching
the stuff that it shouldn't cache (keeping resources allocated across
display close / display reopen is a very bad hack actually :-)
We need to undo some 2.10 fixes and leak these things again to make the
launcher work again.
To follow up on my own comment, I didn't mean that we need to hack
maemo-gtk-2-10 to make the launcher work *at*all*. Setting the old
screen's GtkSettings on the new screen will probably just continue
However, much of the stuff that was "cached" in various places in
gtk-2-6 is now correctly freed. So we gotta either live with a
less-effective launcher, or we need to back out some of these
fixes in order to keep the things again that should actually
be freed on display close.
(In reply to comment #2)
> However, much of the stuff that was "cached" in various places in
> gtk-2-6 is now correctly freed. So we gotta either live with a
> less-effective launcher, or we need to back out some of these
> fixes in order to keep the things again that should actually
> be freed on display close.
Hmmm, I don't really like either of the options, reverting correct fixes
just for the launcher and thus have a leaky gtk upstream or a slower
launcher. What about being able to retrieve such cached stuff in an
opaque data blob(s), and then being able to feed it back? Would that
imply a lot of work, and more importantly would this kind of thing be
I hope you don't talk about adding such hacks to upstream :-) In maemo-gtk
we can of course add such things if required at all.
I have created a booster module that works with 2.10 but does not use the
Display hacks. At least it does no crash with gtk 2.10. You need SVN TRUNK of
maemo-launcher to compile it.
Have a look:
Created an attachment (id=250) [details]
diff against maemo-launcher gtk-booster
Here is also a diff against the stock maemo gtk-booster. Everything touching
the GtkDisplay and Xft has been removed.
I wonder, is there anything that we could pre-initialize in the replacements
We could possible init some of the cairo/pango stuff but I did not yet find
anything in the cairo API that would be useful.
My first test results show, that using the new booster, the gtk hello world
example is speed up by about 25% compared to not using any booster which is
better than nothing.
Created an attachment (id=253) [details]
Improved version of the patch
The old patch was broken somehow, this one is now clean against svn and
contains some stubs for cairo initialisation but that does not work yet.
Created an attachment (id=255) [details]
Patch to support gtk 2.10 and to init cairo
This patch adds a correct (or at least for me working) method to preinit cairo.
It speeds up my test case ("Hello World" from the Gtk+ Tutorial") by 50%.
The problem is that I assume that it does not work if the default font is
different to "Sans 10", so maybe someone finds a solution to detect the default
font without opening a display.
Of course, if you think it is okay to open/close a display within preinit it is
also possible to autodetect the font.
Why are you changing the license terms of the code?:
- * the Free Software Foundation; version 2 of the License.
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
If the original code is only GPLv2 you cannot change it to be under GPLv2 or
later without approval from the copyright holders.
There is also some debug stuff here (in the .c files and in the Makefile) that
should be removed or at least disabled.
Sorry, the license change was not intended! It was just a copy paste problem
and don't want to change the license in any way.
Note that this is still work in progress and that's why I enabled debugging in
Created an attachment (id=256) [details]
Clean version of the patch
Sorry, for the license confusion!
Created an attachment (id=257) [details]
Yet a better patch
After some more testing I found out that I do not need to load a special font
at all for the speed-up which makes the patch a lot simpler.
It still has this change, which seems unrelated:
-booster_gtk_so_CFLAGS = -fPIC
+booster_gtk_so_CFLAGS = -fPIC -DDEBUG
Whoever applies this should probably be careful not to apply that change.
As we have working maemo-launcher in Sardine, lowering severity. Leaving bug
open for the optimisations.
This has been fixed in 0.22-1.