1. 30 Nov, 2018 1 commit
    • Ell's avatar
      app: use gimp_async_add_callback_for_object() in various places · 7c00cf49
      Ell authored
      Use gimp_async_add_callback_for_object(), added in the previous
      commit, instead of gimp_async_add_callback(), in cases where the
      destructor of the object owning the async doesn't wait for the
      async to finish.  This avoids leaking such ongoing asyncs on
      shutdown, during which gimp-parallel either finishes or aborts the
      asyncs: if at this point an async has any registered callbacks, an
      idle source is added for running the callbacks, extending the
      lifetime of the async; however, since we're not getting back into
      the main loop, the idle is never run, and the async (and any
      associated resources) are never freed.
  2. 01 Oct, 2018 1 commit
    • Ell's avatar
      app: add gimp_data_factory_data_cancel() · 6bc0b3b8
      Ell authored
      Add a new GimpData::data_cancel() virtual function, and a
      corresponding gimp_data_factory_data_cancel() function.  This
      function should cancel any ongoing async operations related to the
      factory (i.e., included in its async set), and wait for the
      operations to finish.  Provide a default implementation that simply
      cancels and waits on the factory's async set.
      Use this function to cancel any ongoing operations during factory
      destruction, and in gimp_data_factory_data_free().
      Override this function in GimpFontFactory, for which we can't
      really cancel font loading, and simply cancel and clear the
      factory's async set without waiting for loading to finish, making
      sure that nothing happens (and, in particular, that the factory
      isn't being accessed, since it might be already dead) when loading
      does finish.
  3. 18 Sep, 2018 2 commits
    • Ell's avatar
    • Ell's avatar
      app, libgimp*, modules: don't use g_type_class_add_private() ... · 3b0040c0
      Ell authored
      g_type_class_add_private() and G_TYPE_INSTANCE_GET_PRIVATE() were
      deprecated in GLib 2.58.  Instead, use
      G_ADD_PRIVATE[_DYNAMIC](), and the implictly-defined
      foo_get_instance_private() functions, all of which are available in
      the GLib versions we depend on.
      This commit only covers types registered using one of the
      G_DEFINE_FOO() macros (i.e., most types), but not types with a
      custom registration function, of which we still have a few -- GLib
      currently only provides a (non-deprecated) public API for adding a
      private struct using the G_DEFINE_FOO() macros.
      Note that this commit was 99% auto-generated (because I'm not
      *that* crazy :), so if there are any style mismatches... we'll have
      to live with them for now.
  4. 30 Aug, 2018 1 commit
  5. 05 Aug, 2018 1 commit
    • Michael Natterer's avatar
      Issue #1954 - GIMP-2.99 color changes when converting between... · 8226265b
      Michael Natterer authored
      ...linear and perceptual precision
      Under certain circumstances (e.g. the image has no color profile),
      GimpLayer's implementation of GimpDrawable::convert_type() didn't have
      enough information to do the right color space conversion.
      Intead of messing with stuff like "set profile in between doing a and b",
      simply add a "src_profile" parameter to GimpDrawable::convert_type() so
      the complete color space conversion information is available without
      relying on obscure states that could change in the future.
      Make sure all callers pass the right src_profile, particularly in
      gimp_image_convert_precision(), which also needed fixing.
  6. 02 Aug, 2018 2 commits
    • Jehan's avatar
      app: minor coding-style cleanup. · 5c56f8cb
      Jehan authored
      Adding spaces between function names and parenthese.
      I would normally have just amended the contributed patches and pushed,
      but gitlab is making our review process over-complicated with many
      roundtrips with contributors, and review quality drops. Stating it here
      for the records!
      See commit 70945b89 (where this cleaning
      should have directly been done).
    • ONO Yoshio's avatar
      Fixed that anchor position of text is shifted when text direction is changed. · 70945b89
      ONO Yoshio authored
      anchor of LTR is top-left corner.
      anchor of TTB-RTL is top-right cornner.
      anchor of TTB-LTR is top-left cornner.
  7. 30 Jul, 2018 1 commit
    • ONO Yoshio's avatar
      MR !19: Add support for vertical text writing. · 587d9bbb
      ONO Yoshio authored
      Squashed commit of the following:
      commit ee1ff7d502658cfa1248a13a3f0348495db07eda
      Author: ONO Yoshio <ohtsuka.yoshio@gmail.com>
      Date:   Sun Jul 29 00:31:47 2018 +0900
          Fixed that gimp-text-dir-ttb-* icons are lacked in Symbolic.
      commit d87d012d697628da28fe90199cc04b95b72ba8ef
      Author: ONO Yoshio <ohtsuka.yoshio@gmail.com>
      Date:   Sat Jul 28 16:23:10 2018 +0900
          Fix a typo.
      commit cf0238bf7df56c384cdf3b7ec69557d14740f853
      Author: ONO Yoshio <ohtsuka.yoshio@gmail.com>
      Date:   Sat Jul 28 15:50:57 2018 +0900
          Fixed seg fault error.
      commit b07f60d0
      Author: ONO Yoshio <ohtsuka.yoshio@gmail.com>
      Date:   Fri Jul 27 17:15:34 2018 +0900
          Add support for vertical text writing.
  8. 14 Jul, 2018 1 commit
  9. 11 Jul, 2018 1 commit
  10. 06 Jul, 2018 1 commit
  11. 01 Jul, 2018 1 commit
    • Ell's avatar
      app: add gimp_parallel_run_async_{full,independent}() · b74e600c
      Ell authored
      Remove the "independent" parameter of gimp_parallel_run_async(),
      and have the function always execute the passed callback in the
      shared async thread-pool.
      Add a new gimp_parallel_run_async_full() function, taking, in
      addition to a callback and a data pointer:
        - A priority value, controlling the priority of the callback in
          the async thread-pool queue.  0 is the default priority (used
          by gimp_parallel_run_async()), negative values have higher
          priority, and positive values have lower priority.
        - A destructor function for the data pointer.  This function is
          called to free the user data in case the async operation is
          canceled before execution of the callback function begins, and
          the operation is dropped from the queue and aborted without
          executing the callback.  Note that if the callback *is*
          executed, the destructor is *not* used -- it's the callback's
          responsibility to free/recycle the user data.
      Add a separate gimp_parallel_run_async_independent() function,
      taking the same parameters, and executing the passed callback in
      an independent thread, rather than the thread pool.  This function
      doesn't take a priority value or a destructor (and there's no
      corresponding "_full()" variant that does), since they're pointless
      for independent threads.
      Adapt the rest of the code to the changes.
  12. 28 Jun, 2018 1 commit
    • Ell's avatar
      app: a few async font loading fixes · b5890e05
      Ell authored
      In gimp_data_factory_finalize(), wait on the factory's async set
      after canceling it, and before continuing destruction.  It's not
      generally safe to just abandon an async op without waiting on it
      -- this is a font-specific hack, due to the fact we can't actually
      cancel font loading, and GimpFontFactory is prepared to handle
      Instead, in gimp_font_factory_finalize(), cancel and clear the
      async set, so that GimpDataFactory doesn't actually wait for
      loading to finish.
      In gimp_font_factory_load_async_callback(), don't try to acess the
      factory when the operation is canceled, since cancelation means the
      factory is already dead.  On the other hand, when the opeation
      isn't canceled, make sure to thaw the container even when font
      loading failed, so that we always match the freeze at the begining
      of the operation.
  13. 24 Jun, 2018 1 commit
  14. 06 Jun, 2018 1 commit
  15. 04 Jun, 2018 2 commits
  16. 03 Jun, 2018 5 commits
  17. 02 Jun, 2018 3 commits
  18. 30 May, 2018 2 commits
    • Ell's avatar
      app: restore font list in async callback, not async-set notify handler · 0e19f159
      Ell authored
      When font loading is finished, restore the font list in the
      corresponding async completion callback, and not in the
      "notify::empty" signal handler of the fonts async set
      This solves a problem arising when gimp_fonts_wait() is called
      *inside* a "notify::empty" signal handler, emitted when reloading
      fonts (causing the "empty" property of the fonts async set to
      switch from TRUE to FALSE):  When the wait is over, "empty" will
      switch back from FALSE to TRUE, however, since the "notify" signal
      is non-recursive, the corresponding handler will not be called,
      gimp_fonts_wait() will return *before* the font list is restored,
      and the caller will see an empty font list.  This can happen under
      certain circumstances when reloading fonts while the text tool is
    • Ell's avatar
      app: code cleanup in previous commits · c2731609
      Ell authored
  19. 29 May, 2018 3 commits
    • Ell's avatar
      app, pdb: wait for fonts to load before dependent operations · f2134180
      Ell authored
      Use gimp_fonts_wait(), added in the previous commit, to wait for
      fonts to finish loading before operations that depend on font
      availability.  In particular, this includes font- and text-related
      PDB functions, and text-layer rendering.
    • Ell's avatar
      app: add gimp_fonts_wait() · 0a5a4fed
      Ell authored
      ... which waits for font-loading to complete, using gimp_wait() to
      show a message while waiting.
      Note that we don't currently allow the wait to be canceled, since
      it may have unpredictable effects on plug-ins, but the interface is
      such that the wait might not complete, so calling code should be
      prepared for that.
    • Ell's avatar
      app: use GimpAsyncSet for keeping track of font loading · 1ac2b928
      Ell authored
      Replace the boolean fonts_loading member of Gimp with
      fonts_async_set, which is a GimpAsyncSet object.  This allows us
      to easily respond to the completion of font loading and reloading,
      as will be done in the next commits.
      Additionally, move the call to FcConfigSetCurrent(), used to
      activate the loaded font configuration, from the async thread to
      the main thread, just to be on the safe side, and avoid calling
      FcInitReinitialize() in gimp_fonts_reset() if font loading is still
      in progress, which is unsafe.
  20. 27 May, 2018 3 commits
    • Ell's avatar
      app: add "independent" parameter to gimp_parallel_run_async() · ad8add68
      Ell authored
      Add a boolean "independent" parameter to gimp_parallel_run_async().
      When FALSE, the passed function is run in the shared async thread
      pool; when TRUE, the passed function is run in an independent
      Generally, async operations should run in the async pool, however,
      it might be desirable to run long-standing operations, especially
      ones that can't be canceled, in independent threads.  This avoids
      stalling quicker operations, and shutdown.
      Adapt the rest of the code for the change.  In particular,
      initialize the font cache in an independent thread.
    • Jehan's avatar
      app: output proper info message while fonts are loading. · cfaa3103
      Jehan authored
      To this effect, I add a variable to differentiate the "no-fonts on the
      system" case from "fonts still loading".
    • Jehan's avatar
      Issue #1211: Load fonts in background after startup. · 2484dec7
      Jehan authored
      Fonts should not be blocking startup as this provides a very bad
      experience when people have a lot of fonts. This was experienced even
      more on Windows where loading time are often excessively long.
      We were already running font loading in a thread, yet were still
      blocking startup (thread was only so that the loading status GUI could
      get updated as a feedback). Now we will only start loading and proceed
      directly to next steps.
      While fonts are not loaded, the text tool will not be usable, yet all
      other activities can be performed.
  21. 26 May, 2018 1 commit
    • Ell's avatar
      app: use gimp_parallel_run_async() when loading fonts · 3e92e7a4
      Ell authored
      Replace the custom threading code with a call to
      gimp_parallel_run_async().  This simplifies the code, while
      maintaining the current (blocking) behavior.  In the future, we
      might build upon this to actually load the fonts in the background.
  22. 25 May, 2018 1 commit
  23. 09 May, 2018 1 commit
  24. 05 May, 2018 2 commits
    • Jehan's avatar
      app: add a check on not-NULL string before g_utf8_validate(). · 98a57537
      Jehan authored
      Still looking for possible crash case during gimp_font_list_load_names()
      (cf. bug 795650). g_utf8_validate() segfaults if called with NULL.
      Though looking at pango_font_description_to_string() implementation, it
      doesn't look like it would ever return NULL. Yet it is worth
      double-checking. We don't load font every second anyway.
    • Jehan's avatar
      Bug 795650 - Gimp crashes on start in Windows. · d58f131b
      Jehan authored
      Add more assertion checks (similar to commit d094ab7e).
      This is still not a fix per-se, but at least would make the code a bit
      more robust. In particular FcObjectSetDestroy() could crash if somehow
      FcObjectSetBuild() had returned a NULL pointer. And obviously
      dereferencing a NULL fontset would crash as well.
      Now if any of these happened, no fonts would be loaded. But at least
      GIMP would not crash.
  25. 01 May, 2018 1 commit
    • Jehan's avatar
      app: add some g_return_if_fail() in gimp_font_list_load_names(). · d094ab7e
      Jehan authored
      Some crash happens inside this function (cf. bug 795650) on Windows.
      Because of very inaccurate trace on this OS, it is hard to determine the
      exact issue. Let's at least add some basic check on function parameters.
      This won't fix any core issue, but may make things a bit more robust and
      bugs easier to detect.