Web lists-archives.com

Re: [Discuss] Make a thinner Glib/GTK+ to fit tiny device better

Le lundi 12 octobre 2015 à 23:24 +0800, cee1 a écrit :
> Hi all,
> I'm thinking and interested in the idea of running Glib/GTK+ based
> applications on tiny devices, e.g. wearable devices.
> I notice Tizen employs EFL because it is lightweight and fast. But
> when went through the code, it seems terrible and in a mess.
> Glib is clean and elegant, and with the incoming GSK, GTK+ will be
> polished. I'm thinking how to make Glib/GTK+ thinner ( to make memory
> footprint comparable with EFL's , though I haven't found any 'GTK+ vs
> EFL' benchmark yet...)
> And here are some rough thoughts:
> 1. Make Glib/GTK+ more modular for building, e.g. a configuration
> system similar to linux kernel's. Autoconf do support select in/out
> optional modules, but will be too many configure args with a huge
> options.

GLib is already broken up into a whide amount of shared library. Even
though, shared library tend to create a small size overhead.
Considering this is a supporting library, it's probably not ideal to
try and disable random features. What we endup doing here, is using
static build, so whatever you don't use can later be stripped. It's
more work in regard to the LGPL.

> 2. I notice EFL use some "COW" logic[1], but we already have a much
> clean implementation in GStreamer, that's
> gst_mini_object_make_writable[2]. Then we may merge GstMiniObject
> back
> to glib?

We (taking my GStreamer hat) havent heard of any interest from the GLib
group for lightweight objects. Note that some library ended up also
having these lightweight kind of object, hence may be interesting to
eventually consolidate.

> 3. Remove extra layers. E.g. the malloc implementations in nowadays
> are very powerfull(e.g. jemalloc), hence GSlice can be retired(which
> otherwise introduces an extra cache layer).    Also I'm thinking
> about

I do believe disabling GSLice is already possible.

> providing APIs to make GTK+(also GIO) easily integrated to other
> event
> loop, then we use epoll() on Linux, kqueue() onBSD or even
> libdispatch[3] - client code can use simpler event loop(e.g. no
> locks,
> no recursive main loop support)

This is all fully supported.


Attachment: signature.asc
Description: This is a digitally signed message part

gtk-devel-list mailing list