1. 14 Aug, 2018 1 commit
  2. 13 Aug, 2018 1 commit
    • Debarshi Ray's avatar
      build: Restore optimized builds by default · cfc3985f
      Debarshi Ray authored
      Building with AX_CHECK_ENABLE_DEBUG([yes]), which is what happens by
      default for non-release builds, turns off compiler optimizations and
      overrides any optimization specified via CFLAGS in the build
      environment. This means that the nightly Flatpaks, and almost all
      other non-release builds, are built without any optimization. It's
      very likely that this has a negative impact on the image processing
      loops in the built-in GeglOperations.
      It can be useful to turn off compiler optimizations to get a better
      debugging experience, but it becomes a problem if it stomps over the
      build environment while doing so. The person doing the builds should
      should get to decide between ease of debugging and reasonable
      performance. After all, debugging is not the only thing that a
      developer does. Performance measurements are important too, and one can
      use GDB reasonably well with the Autoconf default, which also happens
      to be what most distributions use, of "-g O2".
      This wouldn't have been such a problem if AX_CHECK_ENABLE_DEBUG
      attached its flags before the values from the environment instead of
      after, because in case of multiple -O options, the last such option is
      the one that's effective.
      Thankfully, "no" doesn't override the environment, which is what
      happens for release builds, and distributions generally set their own
      CFLAGS. Otherwise every single user-facing build would have been
      broken. Note that any release build without CFLAGS set in the
      environment would neither get debug symbols (ie., no "-g") nor any
      compiler optimization because AX_CHECK_ENABLE_DEBUG always suppresses
      the Autoconf defaults of "-g -O2".
      One solution could have been to default to "info" for non-release
      builds and recommend the use of --enable-debug=info while building from
      Git, but that would not address release builds without CFLAGS.
      Given that the only other thing the macro does is to define the NDEBUG
      pre-processor macro when debugging is set to "no", which isn't widely
      used in the GLib-based GNOME platform [1], it seems better to just
      remove it altogether.
      Interestingly, this also seems to unmask some valid cases of
      -Wclobbered and -Wmaybe-uninitialized with Fedora's
      gcc-7.3.1-6.fc27.x86_64 build.
      Fallout from 8f6fb686. The deprecated
      GNOME_DEBUG_CHECK macro didn't set any debugging or optimization flags.
      [1] glib/gio/xdgmime is the only widely used code path where assert(3)
          is used. It's also used in gio/kqueue/dep-list.c, which is
          *BSD-specific and in GTK+'s Broadway backend. All those can
          probably be replaced with g_assert*.
  3. 12 Aug, 2018 2 commits
  4. 11 Aug, 2018 2 commits
  5. 09 Aug, 2018 5 commits
  6. 03 Aug, 2018 1 commit
  7. 01 Aug, 2018 2 commits
    • Debarshi Ray's avatar
    • Debarshi Ray's avatar
      build: Turn off -Wcast-function-type · bb290a1e
      Debarshi Ray authored
      GCC 8 introduced -Wcast-function-type. It is enabled by -Wextra, which
      is on the AX_COMPILER_FLAGS list. Unfortunately, this cannot be sanely
      used with the GNOME platform. It is exceedingly common practice to
      specify a function as a callback that ignores some of the trailing
      parameters passed to it. In fact, the following snippet that's part of
      the g_list_copy_deep documentation triggers -Wcast-function-type:
        another_list = g_list_copy_deep (list,
                                         (GCopyFunc) g_object_ref,
      Disabling warnings like this does go against the recommendation of the
      AX_COMPILER_FLAGS documentation, which suggests the use of #pragmas
      instead. However, unlike passing the flags through the command line,
      attempts to ignore -Wcast-function-type through a #pragma will trigger
      -Wpragmas on older versions of GCC, and, ironically, using
      G_GNUC_CHECK_VERSION to conditionally disable it on newer compilers
      will trigger -Wexpansion-to-defined, again, because of -Wextra.
  8. 30 Jul, 2018 2 commits
  9. 28 Jul, 2018 3 commits
  10. 26 Jul, 2018 1 commit
    • Debarshi Ray's avatar
      flatpak: Simplify TrackerSparqlConnection creation · 6624c0c8
      Debarshi Ray authored
      The Tracker D-Bus services are not part of the Flatpak bundle and are
      accessed from the host operating system. This means that the Tracker
      database cannot be accessed "directly", which causes:
        Tracker-WARNING **: Falling back to bus backend, the direct backend
          failed to initialize: Could not open sqlite3 database:
          unable to open database file
      The database needs to be accessed via D-Bus. So far, this was being
      handled by the fallback error-handling code paths.
  11. 24 Jul, 2018 1 commit
  12. 18 Jul, 2018 5 commits
  13. 13 Jul, 2018 3 commits
  14. 09 Jul, 2018 1 commit
  15. 29 Jun, 2018 6 commits
  16. 28 Jun, 2018 4 commits
    • Debarshi Ray's avatar
      image-view: Reduce memory fragmentation · 491a1822
      Debarshi Ray authored
      Instead of allocating and de-allocating memory for the throwaway Cairo
      surface on every invocation of the GtkWidget::draw virtual method,
      allocate a memory area big enough to draw the entire widget and keep
      re-using it.
    • Debarshi Ray's avatar
      image-view: Rename variables for clarity · ed033da0
      Debarshi Ray authored
    • Debarshi Ray's avatar
      image-view: Rename variables for consistency · 2fcbfc0f
      Debarshi Ray authored
      Use "allocation" instead of "viewport" and "scaled" instead of "real".
    • Debarshi Ray's avatar
      base-item: Use the correct stride value · c3ef33ea
      Debarshi Ray authored
      The stride with which the Cairo surface is created should be the same
      as the one with which data was written to it. The Cairo surface and its
      underlying memory buffer were being created based on the stride
      specified by Cairo, while data was being written to it based on a
      potentially smaller stride value, which could have caused visual
      GEGL_AUTO_ROWSTRIDE represents the product of the bytes per pixel of
      the Babl format with the requested width. This might not match the
      value specified by the Cairo surface because it might be more
      performant to have extra padding at the end of each row to satisfy
      alignment requirements, etc..
      There are no known bugs caused by this, possibly because a
      CAIRO_ARGB32 pixel has a nicely rounded length of 32 bits, which makes
      a mismatch unlikely. However, the possibility cannot be ruled out.
      There was a similar bug in gegl:pixbuf [1] where the stride with which
      a GdkPixbuf was created didn't match the one with which data was read
      from it.
      [1] GEGL commit aaf2477caec750