After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 788810 - Load fonts in background after startup
Load fonts in background after startup
Status: RESOLVED OBSOLETE
Product: GIMP
Classification: Other
Component: General
2.9.6
Other All
: Normal enhancement
: 2.10
Assigned To: GIMP Bugs
GIMP Bugs
Depends on:
Blocks:
 
 
Reported: 2017-10-11 02:00 UTC by AbriPix
Modified: 2018-05-24 18:31 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description AbriPix 2017-10-11 02:00:51 UTC
Loading fonts at startup takes a lot of time. I know I can run GIMP with a parameter that does not load any fonts, but sometimes I need to use text.

I think a better sequence may be loading a few basic fonts at startup. While the user opens an image, sets tools, all other fonts will be loaded in background.
Comment 1 Jehan 2017-10-11 03:03:06 UTC
Yes this is a known issue. Loading in background has been considered but this is also quite a problematic behavior. Some people wants to use text immediately and they would not understand why all their fonts are missing. It has been considered that it could degrade experience more than having people wait for all the fonts to be loaded.

This said, I am not sure this former decision is right. Actually with proper feedback, it may be more interesting to load faster and allow all features but the text tool while fonts load in background. The loading font issue is such a long-time problem that I think we should think to see if better alternatives could be.

By the way, you don't have a long wait at every startup, right? Normally it happens only at the first start, or after a reinstall, etc. But not every time.
Comment 2 Michael Schumacher 2017-10-11 08:17:38 UTC
Just FYI, recently committed changes to fontconfig were advertised as reducing the cache creation time by a factor of 10.

See https://bugs.freedesktop.org/show_bug.cgi?id=64766#c47 ff. and the thread starting at https://lists.freedesktop.org/archives/fontconfig/2017-August/005986.html

If I get https://lists.freedesktop.org/archives/fontconfig/2017-August/005996.html correctly, then part of the motivation to do a thorough scan of the font files was to make sure that their capabilities and glyph coverage are known, and some font bugs can be properly identified.
Comment 3 AbriPix 2017-10-12 15:56:43 UTC
(In reply to Jehan from comment #1)

> 
> By the way, you don't have a long wait at every startup, right? Normally it
> happens only at the first start, or after a reinstall, etc. But not every
> time.

Yes, indeed it takes less than a second on a new system, about 2 seconds when many fonts are installed. OK.
Comment 4 Jehan 2017-10-12 16:22:23 UTC
Please don't close this report. Even though it is bad only at first launch, I still believe this is not good experience. We had reports (from people with a lot lot of fonts) of loading time reaching dozens of minutes, if not mistaken.

Maybe we will consider this fixed with a recent fontconfig version (cf. comment 2, we'll have to test), maybe we could indeed do some background loading (deactivating the text tool only until loading is complete).
I don't know. But let's keep this bug report in the backlog, at least for reminder. :-)
Comment 5 Jehan 2018-05-13 16:31:25 UTC
After discussing with Mitch during LGM, we agreed that loading the fonts in background and not blocking startup waiting for them is indeed the path to follow.
So let's set a hopeful 2.10.x target.
Comment 6 GNOME Infrastructure Team 2018-05-24 18:31:04 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to GNOME's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/gimp/issues/1211.