QtCS2018 Text in Qt

Host: Eskil Abrahamsen Blomfeldt

Presentation given. (I wasn't allowed to upload Powerpoint files to the wiki)

• Asynchronous text
  • Should be symmetric to Image.asynchronous
  • Has the same implications: Implicit size of element changes once image has been loaded
  • Possible issue: For text might have more properties depending on the size than an image usually does, such as the font size. UIs using this property should probably be written with explicitly set text widths for the best result.
  • Should it be an enum instead of a bool? What if we want to have other types, such as "synchronous on first update, and then asynchronous on all subsequent"? Would be inconvenient to express by using the bool. In that case, should Image also be changed? (Qt 6)
  • Defer to render thread or to worker thread? Deferring to render thread might not make any sense, since the results of the layout still needs to be passed back to the GUI thread upon completion to update other properties and alignment and stuff
  • It would probably make sense to use Qt Concurrent for this and always defer the work to other threads, and that the difference between synchronous and asynchronous is just that the former actively waits for the result on the GUI thread.
• FormattedText
  • No one likes the Argument classes
  • We could use template literals from Javascript for the patterns and then the dynamic parts can be any javascript expression
  • Still needs magic to make sure we can preprocess the static parts and save the results, but this can be done internally by having a magic type for the pattern
  • How to do text layouts with line breaks internally in the pattern? Maybe this is not supported, or maybe there is limited support (we could retain possible break points in the glyph runs and do this on the fly, but it could affect some strange corner cases where the line breaks affect text shaping?)
  • A simple way to manage batching which does not require this new class would be some optimization flag that lets you isolate the item from the others.
  • We could also use heuristics to detect this, but it sounds complex and like it may lead to false positives
• Should we have a SimpleText class (or something achieving the same)?
  • Text weights a lot because it supports everything
  • Would it be possible to make something faster and smaller which only supports plain text?
  • There should already be fast paths in place in the text code, but maybe it is not enough?
  • It would be great if we could avoid creating yet another text type for it though.
  • It should at least be checked what type of overhead the existence of things like selections and rich text has
• Should we expose a way to write custom text-based items in the Scenegraph?
  • We don't have to expose the classes themselves, just interfaces and a factory which produces them
  • Custom classes can then call createTextNode() and will get something to use in updatePaintNode().
• Related to previous: Should we centralize all text processing in Qt Quick?
  • Feels like there is currently a lot of duplicated code in TextInput, TextEdit and Text, and if we add even more, there will be even more places.
• Generating distance field cache
  • Already working on this for Qt 5.12
  • This doesn't need to be integrated in build system from the first version, as fonts are usually not updated that often in the design process
  • Enough to have a tool which produces e.g. .qdf files and these can be placed next to the fonts and Qt will automatically pick them up