I am the man that arranges the blocks
I’ve finally restored my personal web server after the WordPress installation(s) I had there got hacked last year, and I decided to migrate this blog there.
if you do not read this blog via Planet GNOME, but you use the syndacation feed, you should subscribe to this feed, instead. if you’re only interested in GNOME-related posts (i.e. the posts that end up in Planet GNOME) the use this feed instead.
one of the challenges of writing a graphics library that is capable of doing what modern UI designers and developers expect is providing the required data types to achieve things like 3D transformations.
with the collective knowledge and attention to detail ((bordering on the OCD)) that the free and open source software community brings to the table I was actually surprised to see that all the code for doing vector and matrix math is usually tucked away into various silos that also come with canvas implementations, physics engines, and entire web browsers. it gets even worse when you want code that used features of modern (and less modern) hardware, and instead all you get are just naive implementations of four floating point values in a structure.
you can trust me when I say that I didn’t want to spend the past seven days writing code that deals with vector and matrix operations, when I wasn’t reading PDFs of Intel architecture opcodes, or ARM NEON instructions; I also didn’t want to know that once you start implementing common operations on matrix types, like projection and unprojection, you get to open a fairly deep can of worms that forces you to implement point (2D and 3D), rectangle, quaternion, and quad types.
luckily, it’s possible to find a bunch of implementations under various stages of maintenance, and under suitable licenses, even though mostly are in C++ and they overlap by just about 60% each; you really need to buckle up and start translating naive matrix determinant code to SIMD four vector data structures, and do a union of all possible API, before you have something you can actually use.
the end result of these seven days is an almost decent, almost complete little utility library that tries to be fairly thin in both what it requires and what it provides. I called it graphene and it’s available in Git. at some point, when I’m actually satisfied with it, I’ll even document it like the grown-up I’m supposed to be. right now, I’ll have to write a ton of tests to check on the math, because I’m pretty sure there must be at ton of bugs in there.
the main question is: what do I intend to use graphene for. the more attentive amongst you, kind readers, will already guess that it’s for the forthcoming GTK+ scene graph API — which is indeed the correct answer, but you’ll have to wait for the next blog post in the series for a proper introduction and description, as well as a road map for the unicorn and ponies fuelled future.
the third, and last day of the DX hackfest opened with a quick recap as to what people have been working on in the past couple of days.
we had a nice lunch nearby, and then we went back to the Endocode office to tackle the biggest topic: a road map for GTK+.
we made good progress on all the items, and we have a fairly clear idea of who is going to work on what. sadly, my optimism on GProperty landing soon did not survive a discussion with Ryan; it turns out that there are many more layers of yak to be shaved, though we kinda agreed on the assumption that there is, in fact, a yak underneath all those layers. to be fair, the work on GProperty enabled a lot of the optimizations of GObject: property notifications, bulk installation of properties, and the private instance data reorganization of last year are just examples. both Ryan and I agreed that we should not increase the cost for callers of property setters — which right now would require asking the GProperty instance to the class of the instance that we’re modifying, which implies taking locks and other unpleasant stuff. luckily, we do have access to private class data, and with few minor modification we can use that private data to store the properties; thus, getting the properties of a class can be achieved with simple pointer offsets and dereferences, without locks being involved. I’ll start working on this very soon, and hopefully we’ll be able to revisit the issue at GUADEC, in time for the next development cycle of GLib.
in the meantime, I kept hacking on my little helper library that provides data types for canvases — and about which I’ll blog soon — as well as figuring out what’s missing from the initial code drop of the GTK+ scene graph that will be ready to be shown by the time GUADEC 2014 rolls around.
I’m flying back home on Saturday, so this is the last full day in Berlin for me. it was a pleasure to be here, and I’d really like to thank Endocode for generously giving us access to their office; Chris Kühl, for being a gracious and mindful host; and the GNOME Foundation, for sponsoring attendance to all these fine people and contributors, and me.
the second day of the hackfest had a pretty big discussion on the roadmap for GTK+.
thanks to Matthias Clasen, we had a list of things to discuss prior to the start of the hackfest, even if Matthias himself would not be present:
during the afternoon we managed to go through the first bullet point of the list, but we made really good progress on it, and we managed to assign each sub-issue to a prospective owner that is going to be in charge of it.
hopefully, we’re going to go through the other points during the rest of the hackfest much more quickly.
we had a fairly productive first day here, at the Endocode offices in Berlin. everyone is pretty excited about working on the overall experience for developers on the GNOME platform.
at first, we decided what to tackle in the next three days, and drafted a rough schedule. the hackfest then broke down into two main groups: the first tackled GObject models for the benefit of GTK+ widgets acting as views; the second worked on the developer documentation available on developer.gnome.org.
I decided to stay on the sidelines for the day, and worked on a small utility library that I’m going to use in the development of GSK, the GTK+ scene graph API that will replace Clutter in the near future; I’m going to do a proper blog post on both things later this week. I’ve also worked a bit on my old nemesis, GProperty. I have really high hopes that after three years of back and forth we’re going to finally land it in GLib, and let people have a better, easier, and more efficient way to define and use GObject properties.
In the evening we went to the Berlin GNOME beers along with the local GNOME community; it’s been a great evening, and we met both familiar faces and new ones.
I’d like to thank Endocode for kindly giving us access to their office in order to host the hackfest, as well as the GNOME Foundation for sponsoring travel attendance of many talented members of the GNOME community.
this is a public announcement.
if you link against PulseAudio, whether you want it or not, you’ll get an automatic dependency on json-c, a small C library that parses JSON and doesn’t have any dependency ((which is arguably a plus for a system daemon)). sadly, json-c leaks symbols all over the place, and one of them is called json_object_get_type ((which returns an integer for I don’t know which reason)).
JSON-GLib, the library that yours truly wrote about 6 years ago to parse JSON using a decent C library as a base, also has a type called json_object_get_type ((which returns a GType for the JsonObject boxed structure, so that you can use them in properties and signal marshallers; as it happens, GType is a long lookalike)).
if you link against PulseAudio and JSON-GLib ((or any other library that depends on JSON-GLib, like Clutter)) then you’ll get a segmentation fault with a weird stack trace, like this one and its duplicates ((since both return values and arguments of the functions above are compatible, the linker won’t moan about it, so you won’t see any warning or error when building your code)).
the solution is to use a version of JSON-GLib greater than 0.16.1, which builds JSON-GLib with the -Bsymbolic linker flag ((another solution is to statically link json-c inside PulseAudio instead of dynamically linking it; another solution is to link json-c with -Bsymbolic; yet another solution would be for PA to not use a dependency to parse JSON – or drop JSON entirely because I can’t for the life of me understand why an audio server is dealing with JSON at all)).
that would be all.
I guess a lot of you, kind readers, are pretty well-acquainted with the current idiomatic way to write a GObject type. it’s the usual boilerplate, plus or minus a bunch of macros:
// header typedef struct _MyObject MyObject; typedef struct _MyObjectPrivate MyObjectPrivate; typedef struct _MyObjectClass MyObjectClass; struct _MyObject { GObject parent_instance; MyObjectPrivate *priv; }; struct _MyObjectClass { GObjectClass parent_class; }; GType my_object_get_type (void); // source struct _MyObjectPrivate { int foo; }; G_DEFINE_TYPE (MyObject, my_object, G_TYPE_OBJECT) static void my_object_class_init (MyObjectClass *klass) { g_type_class_add_private (klass, sizeof (MyObjectPrivate)); } static void my_object_init (MyObject *self) { self->priv = G_TYPE_INSTANCE_GET_PRIVATE (self, my_object_get_type (), MyObjectPrivate); self->priv->foo = 42; }
boring stuff that everyone had to remember ((or commit to a script to autogenerate it)). the last big change in the way people write GObject happened 10 years ago, and it was the addition of per-instance private data. it seems to me like a good way to celebrate that occasion to change this stuff all over again. ;-)
at the latest GTK+ hackfest, Alex and Ryan had a very evil, and very clever idea to solve a problem in how the per-instance private data is laid out in memory. before that, the layout was:
[[[GTypeInstance] GObject] TypeA] TypeB] [TypeAPrivate] [TypeBPrivate]
as you can see, the offset of the private data for each type changes depending at which point in the class hierarchy initialization we are, and can only be determined once the whole class hierarchy has been initialized. this makes retrieving the pointer of the private data a pretty hard problem; one way to solve it is storing the private pointer when we initialize the instance, and we spare ourselves from type checks and traversals. the main problem is that, in order to get to the private data faster, we need to rely on a specific layout of the instance structure, something that is not really nice if we want to have generic accessors to private data ((say, for instance, if we’re re-implementing the way properties are handled in GObject)). for that, it would be really cool if we could only have offsets to through to G_STRUCT_MEMBER().
well, it turns out that if you’re doing memory allocations for the instance you can overallocate a bit, and return a pointer in the middle of the memory you allocated. you can actually allocate the whole private data in a decent layout, and only deal with offsets safely — after all, the type information will store all the offsets for safe access. so, here’s the new layout in memory of a GObject ((well, of any GTypeInstance, really)):
[TypeBPrivate] [TypeAPrivate] [[[[GTypeInstance] GObject] TypeA] TypeB]
that’s neat, isn’t it? now all private data can be accessed simply through offsets, and accessing it should be just as fast as a private pointer.
I can already see people using Valgrind preparing torches and pitchforks — but fear not, my fellow developers: GLib now detects if you’re running under Valgrind, and it will communicate with it ((yes, you can do that, and it’s an impressive amount of crack, luckily for us hidden behind the valgrind.h header provided by the Valgrind folks)) about this new memory layout, as well as keeping a pointer to the beginning of the allocated region, so that you won’t get false positives in your report.
this was the state at the end of the hackfest. on top of that, I decided to contribute a bunch of “syntactic sugar” ((i.e. pre-processor macros)) to cut down the amount of lines and things to remember ((the port of GIO to the new macros lost around 900 lines)), as well as providing a good base towards making GProperty work better, and with fewer headaches.
so, here’s how you create a new GObject type in the Brave New World:
// header typedef struct _MyObject MyObject; typedef struct _MyObjectClass MyObjectClass; struct _MyObject { GObject parent_instance; }; struct _MyObjectClass { GObjectClass parent_class; }; GType my_object_get_type (void); // source typedef struct { int foo; } MyObjectPrivate; G_DEFINE_TYPE_WITH_PRIVATE (MyObject, my_object, G_TYPE_OBJECT) static void my_object_class_init (MyObjectClass *klass) { } static void my_object_init (MyObject *self) { MyObjectPrivate *priv = my_object_get_instance_private (self); priv->foo = 42; }
the my_object_get_instance_private() function is generated by G_DEFINE_TYPE, so you can forget about G_TYPE_INSTANCE_GET_PRIVATE and all that jazz. also, no more g_type_class_add_private() — one less thing to remember is one less thing to screw up. you can still store the private pointer in your instance structure — and if you care about ABI compatibility, you really should — but for new code it’s not necessary. you can finally hide the private data structure inside your source code, instead of having the typedef in your header, sitting there, taunting you. finally, everything is just as fast as it was, as well as backward compatible.
stay tuned for the next blog post, because it’ll finally be about GProperty…
now, that was a title of a Decemberists song that I’d have never expected to use as a blog post title
I did announce it on foundation-list, given that it impacts my position on the Board of Directors of the GNOME Foundation, and I did a sneaky tweet as well, but I guess the blog (and Planet GNOME) is still the Old Fashioned Way™ to do these things — and seeing that Cosimo beat me to a punch, it’s worth saying that I have joined Endless Mobile as well.
my last blog post about my work life was a bit depressing, I guess; I received a ton of support and encouragement from many, many people — too many to thank effectively in the narrow margins of this blog. I did take the announced month off, and I was already on my way to recovery; then I met Matt, who told me about Endless, and what they were trying to do with GNOME, and I felt the absolute need to help them as much as I could. after all, aren’t we trying to make GNOME a viable proposition for OEMs and OSVs to take and put on their own devices? I’m sure we’ll be able to start telling the community at large more details about what we want to achieve, and how.
in the meantime, I expect to see people in San Francisco a bit more often (though I’m still going to be based on London for the foreseeable future), and I’ll obviously be at GUADEC in Brno.
it turns out that this week wasn’t the best possible to hold a hackfest in Boston and Cambridge; actually, it was the worst. what was supposed to be the first day passed with us hacking in various locations, mostly from home, or hotel lobbies. nevertheless, there were interesting discussions on experimental work, like a rework of the drawing and content scrolling model that Alex is working on.
or Day 1 redux
with the city-wide lockdown revoked, we finally managed to meet up at the OLPC offices and start the discussion on Wayland, input, and compatibility; we took advantage of Kristian attending so we could ask questions about client-side decorations, client-side shadows, and Wayland compatibility. we also discussed clipboard, and drag and drop, and the improvements in the API that will be necessary when we switch to Wayland — right now, both clipboard and DnD are pretty tied to the X11 implementation and API.
after lunch, the topic moved to EggListBox and EggFlowBox: scalability, selection, row containers, CSS style propagation, and accessibility.
we also went over a whole set of issues, like positioning popups; high resolution displays; input methods; integrating the Gd widgets into GTK+, and various experimental proposals that I’m sure will be reported by their authors on Planet GNOME soon. :-) it was mostly high level discussion, to frame the problems and bring people up to speed with each problem space and potential/proposed solutions.
we’d all want to thank OLPC, and especially Walter Bender, for being gracious hosts at their office in Cambridge, even on a weekend and the GNOME Foundation.
this is a PSA: if you’re thinking about submitting a talk for GUADEC 2013 in Brno, you have a week to do so. :-)