GNOME Bugzilla – Bug 788643
Some memory/performance improvements
Last modified: 2017-10-27 21:34:34 UTC
Created attachment 361099 [details] [review] testiter: Don't leak PangoFontDescriptions When drawing lots of text (or textnodes rather) in gtk+, these things show up in profiles, especially the use of heap-allocated PangoLayoutIter instances that get free'd at the end of the function anyway. Attached are a few patches, as well as one that fixes a memory leak in tests/testiter.
Created attachment 361100 [details] [review] [PATCH 2/4] layout: Move PangoLayouIter struct to private header
Created attachment 361101 [details] [review] layout/renderer: Don't heap-allocate short lived layout iterators
Created attachment 361102 [details] [review] PangoLayoutIter: Allocate an array of Extents instead of a linked list
Review of attachment 361099 [details] [review]: sure
Review of attachment 361100 [details] [review]: looks fine to me
Review of attachment 361101 [details] [review]: ok, if this shows up on profiles...
Review of attachment 361102 [details] [review]: ok, I guess
lgtm. I'm curious, how did you arrive on these? Where they showing on profiles? What else was showing? Thanks.
This particular example was the imagelist example from https://github.com/baedert/listbox-c after clicking on "scroll". It's just one GtkLabel per row and just ~10 rows, but they get snapshot every frame. We spend around 3.1% in pango_renderer_draw_layout in this case: https://i.imgur.com/a6HSSJM.png after it's at around 2.8%: https://i.imgur.com/GHjHHKK.png One other thing that would be cool to have is a stack allocated PangoGlyphString so we can avoid the g_slice_alloc in pango_glyph_string_copy in gsk_text_node_new: https://i.imgur.com/oi5EmNn.png but that would require public API and you'd have to maintain ABI so maybe ~2.8% is good enough for now :)
Created attachment 361569 [details] [review] PangoLayout: Optimize pango_layout_get_baseline This shows up in profiles when e.g. scrolling in the listbox sample from gtk4-demo. This patch reduces the time taken in pango_layout_get_baseline inside get_layout_location from gtklabel.c from ~0.64% to ~29%.
Actually, I guess that patch removes a pango_layout_check_lines call from _get_baseline.
Ignore me, pango_layout_get_extents_internal calls it as well.