On 2013-02-09 07:24 +0100, Tavmjong Bah wrote:
On Sat, 2013-02-09 at 02:17 +0100, ~suv wrote:
On 2013-02-06 15:15 +0100, Josh Andler wrote:
On Wed, Feb 6, 2013 at 1:24 AM, Tavmjong Bah <tavmjong@...8...> wrote:
I've just checked in code that inserts a list of fonts (and font-fallback lists) that are in a document at the top of the font-family drop-down menu that is in the Text toolbar. The fonts that are in the document are rendered with a blue fill to help distinguish them from the normal list of fonts. If a font is not present on the users system, a red line is drawn on top of the font name.
Let me know what you think of this.
From what I can see, I think it's a great enhancement (haven't tried with a font that doesn't exist yet). The only thing I would suggest adding would be a divider line at the bottom of the list of specially recognized fonts (below the blue and I'm assuming red-lined section) that really adds an extra visual separation from the main list of not used fonts. Effectively the way most word processors do it.
The changes between r12104 and r12105 seem to increase launch time of inkscape trunk noticeably (it now takes longer than current stable): http://bazaar.launchpad.net/~inkscape.dev/inkscape/trunk/revision/12105
Tools: installed fonts count: 'fc-list | wc -l' timing of inkscape: 'time inkscape --verb=FileQuit' (multiple runs -> average of 'real' times)
Inkscape settings: Preferences: default (new) Icons: separate $XDG_CACHE_HOME for each tested revision (trunk)
On Ubuntu 12.10 (Unity, 64bit, VM), ~1500 fonts: stable 0.48.3.1 ~10 sec trunk r11087 ~ 8 sec trunk r12108 ~14 sec
On OS X 10.7 (64bit, X11 backend), ~2700 fonts: stable 0.48.4 ~13.5 sec trunk r12104 ~12.5 sec trunk r12105 ~20.5 sec
On OS X 10.7 (64bit, Quartz backend), ~1750 fonts: stable 0.48.4 ~10 sec trunk r12104 ~ 9 sec trunk r12105/8 ~14 sec
On OS X 10.5 (32bit, X11 backend), ~1300 fonts: stable 0.48.4 ~14 sec trunk r12104 ~13 sec trunk r12106/8 ~22 sec
Questions:
- Can others reproduce these results?
- How much of a concern are these increased launch times?
I am surprised that the r12105 check-in has such a big effect. It does add a function determine where to insert a separator. The function is called at start up once per font family (why?). It does include a strcmp() but I can't see that that would be so slow. If this function is causing a slow down at start up then it should also cause a slow down in scrolling the font list where it is also called. I have less than 100 fonts on my system so I can't really test.
Tests measuring launch times are reproducible here: I rebuilt and timed repeated runs of the relevant revisions (r12103-12107, 12111) on my main system (OS X 10.7, both backends) again, with the same results (noticeably slower to launch with revision >= 12105, compared to stable and revision <= 12104).
Opening the font list drop-down the first time, or scrolling the font list later on is more difficult to measure for comparison... - AFAICT in a new document just opened, scrolling the font list once it has been filled (including the previews) is not noticeably slower (comparing r12104 with r12105 and r12111), but I wouldn't know how to precisely time CPU activity if the list is opened for the first time in the current session (since the list doesn't show the full length and no scrollbar the first time it is opened during a session, monitoring CPU activity seems to be the only indicator of internal font-related activities (building/sorting the list, creating the reviews?)).
Sorry if my concerns seem exaggerated: I'm a bit wary of launch times because concerns/complaints about about font-related delays when launching inkscape trunk are still regularly voiced on the irc channel (e.g. reports about 40-60 sec until the document window opens, on linux systems with 1000-2000 fonts installed, are not uncommon - and these are numbers from before the most recent changes to the font list.)
@Vlada - IIRC you just recently (2013-02-04) reported launch times of 40 or more seconds: did you notice any difference with the most recent builds since then (revision >= 12105)?