Setting a width request is not quite enough, since
gtk_widget_set_size_request() only queues a resize
when the widget is visible. Explicitly force one
here. Without this, the popup sometimes shows up
too small.
This is truly a russian doll of documentation formats:
a string containing <> inside an xml fragment in an |[ ]|
gtk-doc example in markdown in a doc comment.
Sadly, something gets escaping wrong, so the <> end up
literally in the docbook and mess up the last step of
our document formatting, even after turning them into
entities.
Work around this with an extra level of entities that
really shouldn't be necessary.
This flag causes pandoc to emit a proper doctype
declaration and, crucially, namespace declarations
for the xlink namespace that it insists on using
for href attributes. Without this, putting external
links in md documents doesn't survive the journey
through xml.
Commit 0145809a94 replace the response-requested
signal with an action, but didn't actually remove the emission
of that no-longer-existing signal.
Fixes: #2942
Add a table mapping event signals to their event controller
replacements, and a table mapping former GtkContainer
subclasses to their gtk_container_add replacement.
SSave the missing keys as a bitset and iterate over that bitset in the
step function.
Solves the problem with a large UI block at the beginning of a sort
operation when all the keys were generated, in particular when key
generation was slow.
Benchmarks for maximum time taken by a single main loop callback:
initial sort with complex GFileInfo keys
old new
32,000 items 137ms 3ms
128,000 items 520ms 31ms
initial sort with string keys
old new
32,000 items 187ms 1ms
128,000 items 804ms 3ms
When updating a (partially) sorted model, take the known runs for the
existing sort and apply them to the new sort. That way, we don't have to
check the whole model again.
Benchmarks:
appending half the items to a model of strings
old new
512,000 items 437ms 389ms
1,024,000 items 1006ms 914ms
appending 10% of the items to a model of strings
old new
512,000 items 206ms 132ms
1,024,000 items 438ms 301ms
appending 1 item to a model of strings
old new
64,000 items 1.8ms 0.00ms
512,000 items --- 0.01ms
Previously, the sort was not stable when items were added/removed while
sorting or the sort algorithm was changed.
Now the sort looks at the item position (via the key's location in the
keys array) to make sure each comparison stays stable with respect to
this position.
This massively speeds up sorting with expensive sort functions that it's
the most worthwhile optimization of this whole branch.
It's slower for simple sort functions though.
It's also quite a lot slower when the model doesn't support sort keys
(like GtkCustomSorter), but all the other sorters do support keys.
Of course, this depends on the number of items in the model - the number
of comparisons scales O(N * log N) while the overhead for key handling
scales O(N).
So as the log N part grows, generating keys gets more and more
beneficial.
Benchmarks:
initial sort of a GFileInfo model with display-name keys
items keys
8,000 items 715ms 50ms
64,000 items --- 554ms
initial sort of a GFileInfo model with complex keys
items keys
64,000 items 340ms 295ms
128,000 items 641ms 605ms
removing half a GFileInfo model with display-name keys
(no comparisons, just key freeing overhead of a complex sorter)
items keys
512,000 items 14ms 21ms
2,048,000 items 40ms 62ms
removing half a GFileInfo model with complex keys
(no comparisons, just key freeing overhead of a complex sorter)
items keys
512,000 items 90ms 237ms
2,048,000 items 247ms 601ms
