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.

Nicolas

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



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]