Dunst: Make GTK dependency optional

[chronus7]

Being able to disable gtk at compile time would be nice for minimal setups (that is after all the reason, I am using dunst).

I get, that for some rendering tasks, gtk may be inevitable. But if one does not use icons, shouldn't it then be possible to render everything without using gtk (another issue/comment mentioned, that only a small amount of gtk's functions are used anyway)?

[tsipinakis]

In theory this sounds like an easy fix, put all gtk stuff in an #ifdef directive and be done. Unfortunately, in practice, all our drawing code is in a huge lump inside x.c and doing this currently would simply add unnecessary complexity.

I do intend to refactor the drawing code into smaller, easily manageable chunks but it's going to take a while since a lot of it is probably going to need to be rewritten from scratch. I'll consider implementing this depending on the state of the code after the refactor is done.

[chronus7]

Reasonable. Guess I will keep using 1.1 till then. :)

[bebehei]

@tsipinakis Is there any reason, why there is GTK neccessary? There is only one single function call requiring gtk3 all others only require gdk-pixbuf2. So having for a single function call requiring 180MiB of dependencies, while the dunst-package is 166KiB big is quite ridiculous (numbers are for Arch).

In another thread, you mentioned, that dunst needs gtk for icon scaling.

Looking into the cairo docs, I see it can create it's surfaces by PNG and SVG and we can scale the surface at the end.

Alternatively, we can convert the gdk-pixbuf to a PNG stream and create with cairo an image surface with PNG.

So, there are some ways, getting rid of gtk and I think it should be clear, that we should get rid of GTK as a dependency as it bloats up our footprint by factor 1000.

[tsipinakis]

For the reference, dependency on gdk was added in b6f56be97ba01d93843b206bbdab63b030e6e450.

Is there any reason, why there is GTK neccessary?

I am still getting re-acquainted with that part of the code but looking at it the function we currently depend on the most is gdk_pixbug_new_from_file which basically abstracts away all file file loading logic.

Looking into the cairo docs, I see it can create it's surfaces by PNG and SVG and we can scale the surface at the end.

I've looked at that too but according to the freedesktop icon spec we also need to support xpm.

[bebehei]

I am still getting re-acquainted with that part of the code but looking at it the function we currently depend on the most is gdk_pixbuf_new_from_file which basically abstracts away all file file loading logic.

Yeah, but gdk_pixbuf_new_from_file is gdk-pixbuf specific and not gtk/gdk in general. gdk-pixbuf is packaged in every distro separately and gtk requires gdk-pixbuf.

So that single function, what requires gdk in general is gdk_cairo_set_source_pixbuf. And this function is only called once. We just have to translate this function call to its cairo/gdk-pixbuf equivalent and we can drop the whole gtk3 requirement and use gdk-pixbuf as dependency. Which saves massive amount of diskspace consumed only by dependencies.

[tsipinakis]

I've been poking gtk and cairo for a few hours looking for a better way to handle this, I even took a look at gdk_cairo_set_source_pixbuf just in case it was trivial enough to implement ourselves, turns out it isn't since it further depends on gdk_cairo_surface_paint_pixbuf.

---

From what I have seen, exporting it as an image from pixbuf and re-importing it into cairo is the only way to handle this without gtk, even worse while cairo supports it internally it does not expose enough of the API to let us load a png file directly from memory meaning that we have to hack the stream loading capability to work with gdk_pixbuf_save_to_buffer.

I pushed a proof of concept to a new branch but I really don't like how this is implemented (especially having a separate struct just to pass the buffer pointer and size). Additionally I want to test the performance hit of this since this function is called every time the window is redrawn which is fairly common if dunst has been set to follow the mouse pointer.

Any suggestions to improve that code are welcome.

---

@chronus7 As for the scope of this issue, I assume dropping the dependency on gtk and only depending on gtk-pixbuf is enough for your usecase, right?

[bebehei]

(especially having a separate struct just to pass the buffer pointer and size)

What about using GString?

[chronus7]

@tsipinakis: Awesome, that you are looking into this.

As for the scope of this issue, I assume dropping the dependency on gtk and only depending on gtk-pixbuf is enough for your usecase, right?

Yes. That would be sufficient for me.

[tsipinakis]

I ran a few tests using the clock() function:

As it is right now it runs in ~20-30 microseconds and according to my tests when converting it to a png and back goes up to ~200-250 microseconds.

While that's obviously going to vary from CPU to CPU but a 10x overhead is a significant slowdown and I further discovered that this function gets called every time there's a focus change, that's a lot of needless CPU time.

[bebehei]

Fixed in #376