Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Text layout performance

Miklos V
September 28, 2018
82

Text layout performance

Miklos V

September 28, 2018
Tweet

Transcript

  1. Collabora Productivity LibreOffice Conference 2019, Tirana | Miklos Vajna 2

    / 5 Motivation Quoting the TDF wiki: • All over the code base assumes shaping text is cheap • We can do it over and over again • Want to measure the text? Shape it and discard the output afterwards. Want to measure part of the same text? Shape again. Want to find line breaks? Shape again. Want to finally draw it? Shape again. • In contrast, other toolkits typically calculate the layout explicitly: • e.g. GtkLabel has an explicit PangoLayout, etc.
  2. Collabora Productivity LibreOffice Conference 2019, Tirana | Miklos Vajna 3

    / 5 Work done: shared code vcl • StatusBar (thanks to Tamás Bunth) • ListBox • Menu svtools • Ruler Not a cache: just lazy-calculate the layout
  3. Collabora Productivity LibreOffice Conference 2019, Tirana | Miklos Vajna 4

    / 5 Work done: Writer Good news • Everything goes through SwFntObj • Can cache GetTextArray(), DrawTextArray(), GetTextWidth(), GetTextBreak() calls on OutputDevice Bad news • Need a cache: SwFntObj typically doesn’t have a good idea about the lifecycle of the created text layout • For now: SwTextGlyphsKey stores which subset of which text was laid out on which output device • Storing the full output device state is too expensive • Can’t handle everything transparently in VCL
  4. Collabora Productivity LibreOffice Conference 2019, Tirana | Miklos Vajna 5

    / 5 Results Metric: # of layout calls • GenericSalLayout::LayoutText() Measured: one Writer scenario (equivalent of UITests in sw) • 55793 layout calls initially • 18126 layout calls now • Only 32% of the original work is performed baseline sw draw cache ruler cache sw break cache listbox cache 0 10000 20000 30000 40000 50000 60000 # of layouts