font selection is cumbersome with a large number of fonts installed

Bug #1866653 reported by nmaxx on 2020-03-09
18
This bug affects 2 people
Affects Status Importance Assigned to Milestone
Pinta
Medium
Unassigned

Bug Description

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.

nmaxx (nmaxx) on 2020-03-09
summary: - font selection is cumbersone with a large number of font installed
+ font selection is cumbersone with a large number of fonts installed
summary: - font selection is cumbersone with a large number of fonts installed
+ font selection is cumbersome with a large number of fonts installed
Changed in pinta:
importance: Undecided → Medium
status: New → Triaged
tags: added: text-tool
Matt Khouzam (mattkhouzam) wrote :

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.

no longer affects: ubuntu
Cameron White (cameronwhite91) wrote :

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.

Changed in pinta:
milestone: none → 1.8
Matt Khouzam (mattkhouzam) wrote :

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) wrote :

@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) wrote :

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) wrote :
Changed in pinta:
status: Triaged → Fix Committed
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers