[bug #53060] [xlib] Significant slowness with some apps, font-related

[Yavor Doganov]

URL:
<http://savannah.gnu.org/bugs/?53060>

Summary: [xlib] Significant slowness with some apps,
font-related
Project: GNUstep
Submitted by: yavor
Submitted on: Sun 04 Feb 2018 02:06:04 AM EET
Category: Backend
Severity: 3 - Normal
Item Group: Bug
Status: None
Privacy: Public
Assigned to: None
Open/Closed: Open
Discussion Lock: Any

_______________________________________________________

Details:

The xlib backend is nearly unusable with some apps. On my main workstation
(not powerful but with many fonts installed) it takes about a minute for
SimpleAgenda to appear and become responsive. Then if I click on another tab,
I have to wait ~15 seconds; the UI is blocked until then.

The log shows some of these:

2018-02-04 01:00:14.278 SimpleAgenda[24146:24146] attempt to initialize
character set with invalid bitmap

Putting a break on NSCharacterSet.m:206 reveals:


Breakpoint 1, -[NSBitmapCharSet initWithBitmap:] (self=0x5555574a8340,
_cmd=<optimized out>, bitmap=0x5555574140c0) at NSCharacterSet.m:206
206 NSLog(@"attempt to initialize character set with invalid bitmap");
(gdb) p length
$1 = 1114112
(gdb) bt 2
#0 0x00007ffff6848a78 in -[NSBitmapCharSet initWithBitmap:]
(self=0x5555574a8340, _cmd=<optimized out>, bitmap=0x5555574140c0) at
NSCharacterSet.m:206
#1 0x00007ffff68463fc in +[NSCharacterSet
characterSetWithBitmapRepresentation:] (self=<optimized out>, _cmd=<optimized
out>, data=0x5555574140c0)
at NSCharacterSet.m:800
#2 0x00007fffeb20d919 in -[GSXftFontInfo coveredCharacterSet]
(self=0x555555f376f0, _cmd=<optimized out>) at GSXftFontInfo.m:368


The first patch addresses this but the slowness remains. With
--GNU-Debug=NSFont, there is intensive output after the loop in
-enumerateFontsAndFamilies. There are an awful lot of repetitions of the
debug output in -setupAttributes, for the same fonts over and over:

+verabtim+
2018-02-04 01:28:29.778 SimpleAgenda[24287:24287] Loaded font: Samyak Tamil
2018-02-04 01:28:29.805 SimpleAgenda[24287:24287] Loaded font: Noto Sans
Telugu UI
2018-02-04 01:28:29.826 SimpleAgenda[24287:24287] Loaded font: URW Gothic L
2018-02-04 01:28:29.858 SimpleAgenda[24287:24287] Loaded font: TeX Gyre
Cursor
2018-02-04 01:28:29.886 SimpleAgenda[24287:24287] Loaded font: Noto Sans
Malayalam-Bold
2018-02-04 01:28:29.912 SimpleAgenda[24287:24287] Loaded font: STIXGeneral
2018-02-04 01:28:29.948 SimpleAgenda[24287:24287] Loaded font: AnjaliOldLipi
2018-02-04 01:28:29.964 SimpleAgenda[24287:24287] Loaded font: Dingbats
2018-02-04 01:28:29.995 SimpleAgenda[24287:24287] Loaded font: Noto Sans
Oriya-Bold
2018-02-04 01:28:30.023 SimpleAgenda[24287:24287] Loaded font: Chilanka
2018-02-04 01:28:30.049 SimpleAgenda[24287:24287] Loaded font:
LucidaTypewriter
2018-02-04 01:28:30.091 SimpleAgenda[24287:24287] Loaded font: ori1Uni
2018-02-04 01:28:30.120 SimpleAgenda[24287:24287] Loaded font: URW Gothic
L-Demibold
2018-02-04 01:28:30.156 SimpleAgenda[24287:24287] Loaded font: Free
Courier-BoldOblique
2018-02-04 01:28:30.196 SimpleAgenda[24287:24287] Loaded font: FreeSerif-Bold
2018-02-04 01:28:30.227 SimpleAgenda[24287:24287] Loaded font: TeX Gyre Termes
Math
2018-02-04 01:28:30.247 SimpleAgenda[24287:24287] Loaded font: TeX Gyre
Cursor-BoldItalic
2018-02-04 01:28:30.272 SimpleAgenda[24287:24287] Loaded font: Samyak
Gujarati
2018-02-04 01:28:30.297 SimpleAgenda[24287:24287] Loaded font: Noto Sans
Georgian-Bold
2018-02-04 01:28:30.325 SimpleAgenda[24287:24287] Loaded font: Terminal-Bold


The above is just a small snippet from the output. I have to kill the app
with kill(all) from another terminal. CPU usage is intensive, and HDD too if
debug output is enabled. This is reproducible with some apps like
SimpleAgenda, LuserNET, PikoPixel, Preview, Cenon (to an extent), Grr (when
you click on a feed) and especially Charmap. I cannot reproduce with AClock,
Timemon, Gorm, PRICE, FTP, Ink or SystemPreferences.

The second patch introduces glyph caching in a very similar way as it is done
for the other backends. I thought initially that this was the culprit but I
was completely wrong. As I've made it anyway and it is some improvement, I
thought it wouldn't hurt to share it although it doesn't solve the problem.

This bug is reproducible with GUI/Back 0.25.0 as well. I tried to track down
the issue but there are so many hoops through GSLayoutManager/NSGlyphGenerator
that I got utterly confused at the end, especially when I tried to compare the
behavior with the other backends. Perhaps a proper programmer would spot and
solve the bug easily.



_______________________________________________________

File Attachments:


-------------------------------------------------------
Date: Sun 04 Feb 2018 02:06:04 AM EET Name:
0001-xlib-Protect-against-invalid-characters-in-coveredCh.patch Size: 1KiB
By: yavor

<http://savannah.gnu.org/bugs/download.php?file_id=43165>
-------------------------------------------------------
Date: Sun 04 Feb 2018 02:06:04 AM EET Name:
0002-xlib-Add-support-for-glyph-caching.patch Size: 3KiB By: yavor

<http://savannah.gnu.org/bugs/download.php?file_id=43166>

_______________________________________________________

Reply to this item at:

<http://savannah.gnu.org/bugs/?53060>

_______________________________________________
Message sent via/by Savannah
http://savannah.gnu.org/

[Fred Kiefer]

Update of bug #53060 (project gnustep):

Status: None => Confirmed
Assigned to: None => FredKiefer

_______________________________________________________

Follow-up Comment #1:

Normally I wouldn't want to support the xlib backend. We really don't want it
to be used by anybody any more. I did look into this issue just because of you
and your excellent patches and bug reports. I would be very thankful if you
wont provide a package for xlib and also for art in the future. Or at least
mark them as unsupported.

The problem here is that the applications you listed use special characters to
depict key equivalents in their menus. These characters aren't present in the
standard font that the xlib backend is using when trying to display this
string. So the NSAttributedString class tries to find a replacement font for
each of these characters. I tried this myself with the xlib backend and for
PikoPixel this fails for most of the special characters. IN that process the
code has to try every font available for this backend. For the cairo backend
with FT fonts this is a rather fast process. For xlib this takes almost for
ever.
The trick we use for cairo (and opal) is to leave this hard task to
fontconfig.
With your changes it will be a bit faster and more reliable but this wont
resolve the general problem. The only thing that is supportable and could
resolve this issues that I see is to reuse the fontconfig/FCFontEnumerator
class for GSXFT. This is actually not that hard to do, FCFontEnumerator was
extracted from GSXFT.

I am still a bit tiered from FOSDEM and the journey back. So please be
patient, I hope to come up with something usable in the next few days.



_______________________________________________________

Reply to this item at:

<http://savannah.gnu.org/bugs/?53060>

_______________________________________________
Message sent via/by Savannah
http://savannah.gnu.org/

[Yavor Doganov]

Follow-up Comment #2, bug #53060 (project gnustep):

Normally I woldn't want to touch xlib with a barge pole. But Debian is likely
to be removing libart in the very near future so we would have to drop the art
backend. We packaged xlib recently only because I want to have at least two
backends, it's useful for testing purposes. I would like to package opal but
there are issues with missing libraries (lcms) and the GNUstep opal library
clashing with the VoIP opal library that is used by ekiga. Both art and xlib
are clearly marked as deprecated in the package descriptions and the
README.Debian file.

My first approach to this problem was to make GSXftFontInfo inherit from
FCFontInfo (and likewise, GSXftFontEnumerator from FCFontEnumerator,
overriding +faceInfoClass and +fontWithName:). I probably made some grave
mistake(s) because I get:

can't find text container for glyph (internal error)

from NSLayoutManager. If you want I can tidy up that patch and can attach it
for you to take a look. It could spare you some time if my mistake is not
fundamental and there's something little yet essential that I'm missing.

By the way, fontconfig has been a hard dependency for Xft since time
immemoriam so the HAVE_FC branch in the code doesn't make sense to me.

_______________________________________________________

Reply to this item at:

<http://savannah.gnu.org/bugs/?53060>

_______________________________________________
Message sent via/by Savannah
http://savannah.gnu.org/

[Fred Kiefer]

Follow-up Comment #3, bug #53060 (project gnustep):

Thank you for this background information. And yes, looking at your patch
could save me some time, as this is about the approach I want to follow
through. All that font stuff is always a bit harder than it should be and this
is mostly true due the levels of abstractions we have there. You always need
one indirection more :-(

As for the HAVE_FC check, I did introduce that when I first started to use
fontconfig with GNUstep. I am pretty sure it was needed at that time. But
later on when somebody (me?) added that coveredCharacterset method, FC
functions did get used unconditionally. This means for a few years GSXft has
only been usable with fontconfig and we now should make it a hard requirement.
This should reduce the amount of different implementations we have.

_______________________________________________________

Reply to this item at:

<http://savannah.gnu.org/bugs/?53060>

_______________________________________________
Message sent via/by Savannah
http://savannah.gnu.org/

[Yavor Doganov]

Follow-up Comment #4, bug #53060 (project gnustep):

I found my mistake -- lineHeight was not set. Not sure if the patch is
correct but it appears to work. PikoPixel is still slowish but it's bearable,
nothing compared to the previous slowness. Other problematic apps display
reasonably fast (as fast as the backend is capable, I guess).

Please discard my previous patches, this one applies directly to git master.
I'm happy to make any corrections provided that you give me some directions
and I actually understand them.

(file #43175)
_______________________________________________________

Additional Item Attachment:

File name: 0001-xlib-Simplify-code-by-deriving-GSXft-from-FC-classes.patch
Size:18 KB


_______________________________________________________

Reply to this item at:

<http://savannah.gnu.org/bugs/?53060>

_______________________________________________
Message sent via/by Savannah
http://savannah.gnu.org/

[Fred Kiefer]

Update of bug #53060 (project gnustep):

Status: Confirmed => Ready For Test
Open/Closed: Open => In Test

_______________________________________________________

Follow-up Comment #5:

Thank you for the excellent patch. I like patches that remove more code than
they add.
The only thing I did change is the value of lineHight. In the old code
ascender - descender was used and this is the value I am using as well. That
way we have the least change.

PikoPixel is still very slow, but it wasn't designed to work with the xlib
backend.

_______________________________________________________

Reply to this item at:

<http://savannah.gnu.org/bugs/?53060>

_______________________________________________
Message sent via/by Savannah
http://savannah.gnu.org/