font selection is cumbersome with a large number of fonts installed

[nmaxx]

Version: Pinta 1.6

The font selection combo-box requires you to scroll through the whole list of fonts to find the one you want. There is no way of just typing a font name to get there quicker, nor is there a scrollbar.

[Matt Khouzam (mattkhouzam)]

I wrote down a small investigation here. You probably already know it though but thought it could help.

Description of issue:
when you have too many fonts,

To reproduce:
* Download a font pack, say with 1000 fonts.
* In Pinta open an image
* click on `Text`
* select the font drop down

The UI thread will hang. This makes drawing text functionally impossible in Pinta when you have too many fonts.

On a Ryzen 7 2700:
Pinta freezes for 45 seconds when there are 2300 fonts in the system.
Opening the combobox then takes ~1:10 and is unusable as the list is larger than the screen.

Fails on 3 different machines here all with different distributions and versions of Pinta.

confirmed to be an issue on 1.6-2

Potential hint?
I am pretty certain this is a combobox issue on GTK's side and making it virtual with a scroll would solve the problem.

[Cameron White (cameronwhite91)]

Thanks! That matches some of my findings from bug 1311873, I also noticed that the combobox was eagerly rendering all of the font previews, and I couldn't find a good way to prevent that.

[Matt Khouzam (mattkhouzam)]

I did some investigation, a virtual comboboxes would help, but it is hiding the root cause:

I traced the code, and have found the following issues:

Most of the time is spent outside of Pinta, but rather in GTK/GTKSharp. It is probably using a sub-optimal path.

The program is running all of this in the UI thread though, and it freezes for the user for over 90 seconds, often timing out and cancelling the operation.

[Matt Khouzam (mattkhouzam)]

@Cameron White

I couldn't find a way to fix this either yet. Some more issues, the combobox does a "double render" over the main box. The first render being the first font in the list, then immediately after, it renders the proper one. fixing this would potentially double the speed, but that would not be enough.

A sad workaround would be to not chance the font on the combobox but have a preview pane?

I am attaching an excel table showing the execution flow with times in a more human friendly format. You surely understand the problem better than I do, so this might help resolve it! :)

[Cameron White (cameronwhite91)]

Thanks, yeah I'm thinking that the best approach will be to avoid the combobox and use something like the standard GTK font button, which can launch a preview pane that doesn't have this issue.

[Cameron White (cameronwhite91)]

This should be fixed in the GTK3 branch by https://github.com/PintaProject/Pinta/commit/6535ce2c70cac51dd00ec754e49c10799d3fc6db

[Matt Khouzam (mattkhouzam)]

Hi, It looks like with "Ubuntu 20.04.2 LTS" the slow down still exists with v1.7 and 1.8 from the PPAs.

[Cameron White (cameronwhite91)]

Yeah, the daily builds PPA is still a GTK2 build from the master branch. For testing, the GTK3 builds are available here: https://github.com/PintaProject/Pinta/releases/tag/dev-preview-builds