Re: Introspection data generation error in evince (autotools vs meson)
Just as a follow up to this for the archives, since it has been fixed in Evince[0]: - the issue is caused by a double declaration of `GType ev_document_model_get_type (void)`—one by the G_DECLARE_FINAL_TYPE at line 33, and one explicit at line 57. This confuses the g-ir-scanner parser, and would be nice to track it down a bit further - next time, you probably want to use gir-devel-list for this kind of issues, not gtk-app-devel-list Ciao, Emmanuele. [0]: https://gitlab.gnome.org/GNOME/evince/merge_requests/82 On Fri, 7 Sep 2018 at 07:35, Iñigo Martínez via gtk-app-devel-list < gtk-app-devel-list@gnome.org> wrote: > Hello, > > I have recently started porting evince to meson. The port is almost > complete but I have an issue with the generation of introspection data of > one of its libraries, `libevview3`, which I haven't been able to figure out > due to my limited introspection knowledge. > > The introspection build parameters are as follows in the autotools' > Makefile[0]: > > ``` > INTROSPECTION_COMPILER_ARGS = --includedir=$(top_builddir)/libdocument > > EvinceView-$(EV_API_VERSION).gir: libevview3.la > EvinceView_@EV_API_VERSION_U@_gir_FILES = \ > $(INST_H_SRC_FILES) \ > $(INST_H_BUILT_FILES) \ > $(filter %.c,$(libevview3_la_SOURCES)) > EvinceView_@EV_API_VERSION_U@_gir_INCLUDES = GLib-2.0 GObject-2.0 Gio-2.0 > Gdk-3.0 GdkPixbuf-2.0 Gtk-3.0 > EvinceView_@EV_API_VERSION_U@_gir_LIBS = libevview3.la > $(top_builddir)/libdocument/libevdocument3.la > EvinceView_@EV_API_VERSION_U@_gir_CFLAGS = \ > -I$(top_srcdir) \ > -I$(top_builddir) \ > -I$(top_srcdir)/libdocument \ > -I$(top_builddir)/libdocument \ > -DEVINCE_COMPILATION > EvinceView_@EV_API_VERSION_U@_gir_EXPORT_PACKAGES = > evince-view-$(EV_API_VERSION) > EvinceView_@EV_API_VERSION_U@_gir_SCANNERFLAGS = \ > --add-include-path=$(top_builddir)/libdocument \ > > > --include-uninstalled=$(top_builddir)/libdocument/EvinceDocument-$(EV_API_VERSION).gir > \ > --identifier-prefix=Ev \ > --symbol-prefix=ev > INTROSPECTION_GIRS = EvinceView-$(EV_API_VERSION).gir > > girdir = $(datadir)/gir-1.0 > gir_DATA = EvinceView-$(EV_API_VERSION).gir > > typelibsdir = $(libdir)/girepository-1.0 > typelibs_DATA = EvinceView-$(EV_API_VERSION).typelib > ``` > > These produces the following command lines: > > ``` > CPPFLAGS="" CFLAGS="-g -O2" LDFLAGS="-L/home/imartinez/jhbuild/install/lib > " CC="gcc" PKG_CONFIG="/usr/bin/pkg-config" GI_HOST_OS="" DLLTOOL="false" > /usr/bin/g-ir-scanner --namespace=EvinceView --nsversion=3.0 > --libtool="/bin/bash ../libtool" --include=GLib-2.0 --include=GObject-2.0 > --include=Gio-2.0 --include=Gdk-3.0 --include=GdkPixbuf-2.0 > --include=Gtk-3.0 --pkg-export=evince-view-3.0 --library=libevview3.la > --library=../libdocument/libevdocument3.la > --add-include-path=../libdocument > --include-uninstalled=../libdocument/EvinceDocument-3.0.gir > --identifier-prefix=Ev --symbol-prefix=ev --cflags-begin -I.. -I.. > -I../libdocument -I../libdocument -DEVINCE_COMPILATION --cflags-end > ev-document-model.h ev-jobs.h ev-job-scheduler.h ev-print-operation.h > ev-stock-icons.h ev-view.h ev-view-presentation.h ev-view-type-builtins.h > ev-annotation-window.c ev-document-model.c ev-form-field-accessible.c > ev-image-accessible.c ev-jobs.c ev-job-scheduler.c ev-link-accessible.c > ev-page-accessible.c ev-page-cache.c ev-pixbuf-cache.c ev-print-operation.c > ev-stock-icons.c ev-timeline.c ev-transition-animation.c ev-view.c > ev-view-accessible.c ev-view-cursor.c ev-view-presentation.c > ev-media-player.c libevview3.la --output EvinceView-3.0.gir > g-ir-scanner: link: /bin/bash ../libtool --mode=link --tag=CC gcc -o > > /home/imartinez/Development/gnome/evince-at/libview/tmp-introspectfyj_c9fn/EvinceView-3.0 > -export-dynamic -g -O2 > > /home/imartinez/Development/gnome/evince-at/libview/tmp-introspectfyj_c9fn/EvinceView-3.0.o > -L. libevview3.la ../libdocument/libevdocument3.la > -L/home/imartinez/jhbuild/install/lib -lgio-2.0 -lgobject-2.0 > -Wl,--export-dynamic -lgmodule-2.0 -pthread -lglib-2.0 > -L/home/imartinez/jhbuild/install/lib > libtool: link: gcc -o > > /home/imartinez/Development/gnome/evince-at/libview/tmp-introspectfyj_c9fn/.libs/EvinceView-3.0 > -g -O2 > > /home/imartinez/Development/gnome/evince-at/libview/tmp-introspectfyj_c9fn/EvinceView-3.0.o > -Wl,--export-dynamic -pthread -Wl,--export-dynamic -L. > ./.libs/libevview3.so ../libdocument/.libs/libevdocument3.so > -L/home/imartinez/jhbuild/install/lib -lgio-2.0 -lgobject-2.0 -lgmodule-2.0 > -lglib-2.0 -pthread -Wl,-rpath -Wl,/tmp/evince/lib > g-ir-scanner: EvinceView: warning: 2 warnings suppressed (use --warn-all to > see them) > ``` > > This command creates the `EvinceView-3.0.gir` file properly. I tried to > replicate this on meson by using the same parameters[1]: > > ``` > incs = [ > 'Gdk-3.0', > 'GdkPixbuf-2.0', > 'Gio-2.0', > 'GLib-2.0', > 'GObject-2.0', > 'Gtk-3.0', >
Re: An alternative to gdk-pixbuf
On Wed, Sep 05, 2018 at 08:25:05PM +0200, Magnus Bergman wrote: > Gegl is great for image editing. But not as much for simple viewing. It > doesn't do animation People have been creating and playing videos with it: http://gegl.org/gcut.html > Also it only loads images from the > file system and is a bit bulky to use. The existing codecs aren't good, but they do support GIO URIs through GFile and streams. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: An alternative to gdk-pixbuf
Hey Magnus,
I haven't yet worked my way through the whole thread. It's pretty
long and will take me a while longer, but I did want to mention a
few things before the weekend draws me away from the computer.
On Wed, Sep 05, 2018 at 12:02:45AM +0200, Magnus Bergman wrote:
> Over the years it has been discussed from time to time to replace
> gdk-pixbuf with something else[1][2]. Something was even in the making
> (I guess over ten years ago) but it never replaced gdk-pixbuf
> apparently. Now I don't even remember what it was called. And something
> else called pig was proposed more recently.
As Emmanuele mentioned, if you ignore the use-case of loading icons
in GTK, and focus on image applications dealing with high resolution
images, then GEGL [1] is the way to go. It's a GObject-based image
processing framework that's used by GIMP and GNOME Photos, and is
way more advanced than anything that we have in the GNOME platform.
If you use GIMP 2.10 or practically any version of GNOME Photos, then
all the image decoding and processing is happening with GEGL.
A GeglBuffer is the equivalent of GdkPixbuf in GEGL. It can:
(a) Be converted to and from a GdkPixbuf. That makes porting trivial
and boosts interoperability.
(b) Handle massive images that are larger than the amount of physical
RAM available on the system. This is achieved by spliting the
pixels into smaller tiles that get transparently swapped out of
memory into a disk-backed cache when necessary.
It can be dumbed down into a GdkPixbuf-like linear sequence of
bytes, if need be.
(c) Represent a whole horde of pixel formats, colour spaces, bit depths,
etc. [2], which can be programmatically extended at run-time.
(d) Automatically convert between pixel formats, colour spaces, bit
depths, etc., with accelerated fast paths.
(e) Be serialized into a named file, which is interesting for passing
pixels across process boundaries.
(f) Use mipmaps for scaling, rendering and processing the pixels.
(g) Be used with OpenCL.
(h) Do all that and is still fast. Try zooming in and out in GNOME
Photos.
Not to mention a vast array of image processing operations. If it's in
GIMP, it's in GEGL. Interesting operations are ported from elsewhere,
and there's a constant flow of new things under development.
> One major reason to replace gdk-pixbuf has been the long term goal to
> phase out GDK in favour of cairo.
De/encoding images and manipulating the pixels is related to rendering
them on the screen, but aren't necessarily the same thing. It's
important to ensure that the pixels can be efficiently drawn, but I
wouldn't add a hard dependency on the drawing framework. For example,
GEGL has fast paths for drawing with Cairo, but doesn't mandate it.
It also doesn't require GTK, even though it has helper widgets for it.
That's why GIMP 2.10 and GNOME Photos can use the same libgegl-0.4.so,
even though they use different widget toolkits (GTK 2.x versus 3.x).
> This is how to convert an SVG file to a PNG file.
>
> cairo_surface_t *surface = abydos_load("image/svg+xml",
> "example.svg"); cairo_surface_write_to_png(surface, "example.png");
> cairo_surface_destroy(surface);
>
> This is how to convert the second frame of a GIF animation to PNG.
>
>abydos_t *ar = abydos_create_from_file("image/gif", "example.gif");
>abydos_set_frame(ar, 1);
>cairo_surface_t *surface = abydos_get_image_surface(ar, 0);
>abydos_destroy(ar);
>cairo_surface_write_to_png(surface, "example.png");
>cairo_surface_destroy(surface);
I don't see any error handling. Maybe I should read the actual code.
Either way, as Emmanuele mentioned, it's really important to have
support for GIO facilities like GCancellable, GFile, streams,
GAsyncResult-based asynchronous APIs, etc..
If you look closely at GEGL, you'll see that while it already has
codecs, they are missing these requirements. It's an artifact of
GIMP historically having it's own in-house codecs.
However, that's changing. I have a work-in-progress GNOME Photos
branch [3] that prototypes a better codec API for GeglBuffer.
See:
*
https://gitlab.gnome.org/GNOME/gnome-photos/blob/wip/rishi/buffer-decoder/src/photos-gegl-buffer-io.h
*
https://gitlab.gnome.org/GNOME/gnome-photos/blob/wip/rishi/buffer-decoder/src/photos-gegl-buffer-loader.h
One obvious thing is that it looks almost identical to the corresponding
GdkPixbuf API. That's an explicit goal to make porting trivial.
Of course, one could use the GdkPixbuf codecs for I/O and then covert
to and from a GeglBuffer. But then you wouldn't be able to handle RAWs
or higher bit-depth PNGs and will likely run into problems with your
80 megapixel images [4] - things that a good image application will
care about. :)
> I've been in contact with a two creators of image viewers
Which ones? Just curious. :)
> What it all comes down to is that using a bigger variety of software
> creates a bigger attack surface. Viewing a lot
Re: An alternative to gdk-pixbuf
On Thu, 2018-09-06 at 11:39 +0100, Emmanuele Bassi via gtk-devel-list wrote: > On Wed, 5 Sep 2018 at 19:25, Magnus Bergman < > magnus.berg...@snisurset.net> wrote: > > On Wed, 5 Sep 2018 17:28:22 +0100 > > Emmanuele Bassi wrote: > > > > > We're phasing out Cairo in favour of the CSS rendering model, > > > implemented on top of OpenGL and Vulkan, as it's the API that > > most > > > closely matches the requirements of GTK. > > > > I'm not sure I quite understand what you are saying. What does this > > mean for image loading if terms of actual implementation? What > > would > > ideally happen then GTK+ needs to load an image (because the > > application called gtk_image_new_from_file() for example)? > > > > We're still using GdkPixbuf, and for the 4.0 API series we still have > GdkPixbuf types exposed in the GTK API. > > For future API series (5.x, 6.x, …) we may revisit this, with the > option of moving icon loading into GTK itself. This uncertainty is the reason why I didn't work on moving the thumbnailing code somewhere else, as it's bound to be made irrelevant sooner rather than later. > > Gegl is great for image editing. But not as much for simple > > viewing. > > This is debatable. If I'm viewing a 4000x4000 RGB image on a hidpi > display I'm already pushing gdk-pixbuf and cairo to their limits > because of the scaling factor applied to the window — not only the > buffer gets loaded uncompressed to allow for zooming, but the image > viewer needs to render a CPU-scaled down copy of the image. > > Sure, for viewing a 500x400px image macro for a meme we're fine; but > we're fine with gdk-pixbuf as well, so there's really no need to > change to a different image loading library. I concur, 4000x4000 would likely OOM your machine, and it's not really fixable: https://gitlab.gnome.org/GNOME/gdk-pixbuf/issues/30 Viewers should use GEGL, and GEGL should be taught about more formats. That still leaves many GIF files unhandled though, and I'm not sure we'd want apps writing their own GIF loader, seeing how complicated that is. > In the near future, I'll very likely deprecate most of > > GdkPixbuf's > > > API, except for the I/O operations; I'd also be happy to seal off > > > most of its internals, within the ABI stability promise, to avoid > > > leakage of internal state. > > > > Will the loader plugin API go away, you think? > > No API will ever go away: there are no plans for a gdk-pixbuf-3.0. > The deprecations would mostly apply to API that is either long since > been replaced by Cairo (scale/composite), or that is weirdly ad hoc, > like saturate_and_pixelate(). Ideally, I'd like to deprecate the > option to build gdk-pixbuf without depending on GIO to do MIME type > sniffing, as GIO has been fixed to work on Windows and macOS, and it > is a required dependency anyway. That's probably fine, though the current code in the stack is dumb as rocks, and will try to thumbnail a JPG file with the PNG decoder if the suffix is incorrect. The error message is also obnoxious, so that'll need fixing before removing the content type sniffing. > The animation API is pretty much a garbage fire, so it may go on the > chopping block as well. Of course, deprecated API will keep working > as well—or as badly—as it works today, so people can still use it. > Moving pixbuf loaders to separate processes, and wrap them in > sandboxes, would be a fairly good thing to do; it need to be decided > at run time, though, because there are many users of GdkPixbuf that > already run in a sandbox, which prevents creating smaller sandboxes > inside it. That'd be best left to an API that can do that natively, with the API being thought out ahead of time. In the short term, my wishlist/TODO list would be: - somebody writes a GIF loader that is readable, and passes the test suite. - we disable every loader by default except the ones that the core desktop needs - image viewers that rely on gdk-pixbuf ship their additional loaders in the app's Flatpak[1]. That would already reduce the attack surface for gdk-pixbuf. On a sidenote, I also use gdk-pixbuf as a pixel-perfect drawing API for thumbnailers: https://gitlab.gnome.org/Archive/gnome-nds-thumbnailer/blob/master/gnome-nds-thumbnailer.c#L72 [1]: I recently did this to add webp comics support to the evince Flatpak: https://gitlab.gnome.org/GNOME/evince/merge_requests/50 ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Introspection data generation error in evince (autotools vs meson)
Hello, I have recently started porting evince to meson. The port is almost complete but I have an issue with the generation of introspection data of one of its libraries, `libevview3`, which I haven't been able to figure out due to my limited introspection knowledge. The introspection build parameters are as follows in the autotools' Makefile[0]: ``` INTROSPECTION_COMPILER_ARGS = --includedir=$(top_builddir)/libdocument EvinceView-$(EV_API_VERSION).gir: libevview3.la EvinceView_@EV_API_VERSION_U@_gir_FILES = \ $(INST_H_SRC_FILES) \ $(INST_H_BUILT_FILES) \ $(filter %.c,$(libevview3_la_SOURCES)) EvinceView_@EV_API_VERSION_U@_gir_INCLUDES = GLib-2.0 GObject-2.0 Gio-2.0 Gdk-3.0 GdkPixbuf-2.0 Gtk-3.0 EvinceView_@EV_API_VERSION_U@_gir_LIBS = libevview3.la $(top_builddir)/libdocument/libevdocument3.la EvinceView_@EV_API_VERSION_U@_gir_CFLAGS = \ -I$(top_srcdir) \ -I$(top_builddir) \ -I$(top_srcdir)/libdocument \ -I$(top_builddir)/libdocument \ -DEVINCE_COMPILATION EvinceView_@EV_API_VERSION_U@_gir_EXPORT_PACKAGES = evince-view-$(EV_API_VERSION) EvinceView_@EV_API_VERSION_U@_gir_SCANNERFLAGS = \ --add-include-path=$(top_builddir)/libdocument \ --include-uninstalled=$(top_builddir)/libdocument/EvinceDocument-$(EV_API_VERSION).gir \ --identifier-prefix=Ev \ --symbol-prefix=ev INTROSPECTION_GIRS = EvinceView-$(EV_API_VERSION).gir girdir = $(datadir)/gir-1.0 gir_DATA = EvinceView-$(EV_API_VERSION).gir typelibsdir = $(libdir)/girepository-1.0 typelibs_DATA = EvinceView-$(EV_API_VERSION).typelib ``` These produces the following command lines: ``` CPPFLAGS="" CFLAGS="-g -O2" LDFLAGS="-L/home/imartinez/jhbuild/install/lib " CC="gcc" PKG_CONFIG="/usr/bin/pkg-config" GI_HOST_OS="" DLLTOOL="false" /usr/bin/g-ir-scanner --namespace=EvinceView --nsversion=3.0 --libtool="/bin/bash ../libtool" --include=GLib-2.0 --include=GObject-2.0 --include=Gio-2.0 --include=Gdk-3.0 --include=GdkPixbuf-2.0 --include=Gtk-3.0 --pkg-export=evince-view-3.0 --library=libevview3.la --library=../libdocument/libevdocument3.la --add-include-path=../libdocument --include-uninstalled=../libdocument/EvinceDocument-3.0.gir --identifier-prefix=Ev --symbol-prefix=ev --cflags-begin -I.. -I.. -I../libdocument -I../libdocument -DEVINCE_COMPILATION --cflags-end ev-document-model.h ev-jobs.h ev-job-scheduler.h ev-print-operation.h ev-stock-icons.h ev-view.h ev-view-presentation.h ev-view-type-builtins.h ev-annotation-window.c ev-document-model.c ev-form-field-accessible.c ev-image-accessible.c ev-jobs.c ev-job-scheduler.c ev-link-accessible.c ev-page-accessible.c ev-page-cache.c ev-pixbuf-cache.c ev-print-operation.c ev-stock-icons.c ev-timeline.c ev-transition-animation.c ev-view.c ev-view-accessible.c ev-view-cursor.c ev-view-presentation.c ev-media-player.c libevview3.la --output EvinceView-3.0.gir g-ir-scanner: link: /bin/bash ../libtool --mode=link --tag=CC gcc -o /home/imartinez/Development/gnome/evince-at/libview/tmp-introspectfyj_c9fn/EvinceView-3.0 -export-dynamic -g -O2 /home/imartinez/Development/gnome/evince-at/libview/tmp-introspectfyj_c9fn/EvinceView-3.0.o -L. libevview3.la ../libdocument/libevdocument3.la -L/home/imartinez/jhbuild/install/lib -lgio-2.0 -lgobject-2.0 -Wl,--export-dynamic -lgmodule-2.0 -pthread -lglib-2.0 -L/home/imartinez/jhbuild/install/lib libtool: link: gcc -o /home/imartinez/Development/gnome/evince-at/libview/tmp-introspectfyj_c9fn/.libs/EvinceView-3.0 -g -O2 /home/imartinez/Development/gnome/evince-at/libview/tmp-introspectfyj_c9fn/EvinceView-3.0.o -Wl,--export-dynamic -pthread -Wl,--export-dynamic -L. ./.libs/libevview3.so ../libdocument/.libs/libevdocument3.so -L/home/imartinez/jhbuild/install/lib -lgio-2.0 -lgobject-2.0 -lgmodule-2.0 -lglib-2.0 -pthread -Wl,-rpath -Wl,/tmp/evince/lib g-ir-scanner: EvinceView: warning: 2 warnings suppressed (use --warn-all to see them) ``` This command creates the `EvinceView-3.0.gir` file properly. I tried to replicate this on meson by using the same parameters[1]: ``` incs = [ 'Gdk-3.0', 'GdkPixbuf-2.0', 'Gio-2.0', 'GLib-2.0', 'GObject-2.0', 'Gtk-3.0', libevdocument_gir[0], ] gnome.generate_gir( [libevview, libevdocument], sources: sources + headers + [enum_sources[1]], includes: incs, nsversion: ev_api_version, namespace: 'EvinceView', identifier_prefix: ev_code_prefix, symbol_prefix: ev_code_prefix.to_lower(), export_packages: 'evince-view-' + ev_api_version, extra_args: '-DEVINCE_COMPILATION', install: true, ) ``` These produces the following command line: ``` /usr/bin/g-ir-scanner -pthread -I/home/imartinez/jhbuild/install/include/glib-2.0 -I/home/imartinez/jhbuild/install/lib/glib-2.0/include -I/usr/include/gobject-introspection-1.0 --no-libtool --namespace=EvinceView --nsversion=3.0 --warn-all --output libview/EvinceView-3.0.gir -DEVINCE_COMPILATION -I/home/imartinez/Development/gnome/evince/libview
