Until now we used our own, well-aged C-style implementation of quick sort, based on code from 1992/93. Apart from being old (which is not bad as such), this code had some
disadvantages, namely:
- It was not typesafe and invocations could not be optimized by inlining.
- [Quick Sort](https://en.wikipedia.org/wiki/Quicksort) has a worst case performance of O(n<sup>2</sup>).
- Quick Sort can recurse deeply and thus cause stack overflows.
- On Windows, [Control Flow Guard](https://learn.microsoft.com/en-us/windows/win32/secbp/control-flow-guard) inspects any function invocation via function pointers to check if the called function was known at compile time. This comes with a [notable overhead](https://bugzilla.mozilla.org/show_bug.cgi?id=1842079) when calling the compare function repeatedly.
`std::sort` and `std::stable_sort` are preferred and have an optimal, guaranteed worst case performance.
Differential Revision: https://phabricator.services.mozilla.com/D181339
Until now we used our own, well-aged C-style implementation of quick sort, based on code from 1992/93. Apart from being old (which is not bad as such), this code had some
disadvantages, namely:
- It was not typesafe and invocations could not be optimized by inlining.
- [Quick Sort](https://en.wikipedia.org/wiki/Quicksort) has a worst case performance of O(n<sup>2</sup>).
- Quick Sort can recurse deeply and thus cause stack overflows.
- On Windows, [Control Flow Guard](https://learn.microsoft.com/en-us/windows/win32/secbp/control-flow-guard) inspects any function invocation via function pointers to check if the called function was known at compile time. This comes with a [notable overhead](https://bugzilla.mozilla.org/show_bug.cgi?id=1842079) when calling the compare function repeatedly.
`std::sort` and `std::stable_sort` are preferred and have an optimal, guaranteed worst case performance.
Differential Revision: https://phabricator.services.mozilla.com/D181339
This adds support for the experimental `invoketarget` and `invokeaction`
attributes, as specified in the open-ui "Invokers" explainer.
(https://open-ui.org/components/invokers.explainer/)
The `invoketarget` attribute maps to the IDL `invokeTargetElement`,
similar to `popoverTargetElement`, and the `invokeaction` is a freeform
string.
The Button behaviour checks for `invokeTargetElement` in its activation
behaviour, and dispatches an `InvokeEvent` if there is one.
This also adds some basic scaffolding for `handleInvokeInternal` which
will allow elements to provide their own invocation action algorithms.
Differential Revision: https://phabricator.services.mozilla.com/D190449
They were added in bug 292981 but this interface is not great,
as it is poll-based. Instead, we want a registry key change
notification of sorts.
Removing this simplifies upcoming patches.
Differential Revision: https://phabricator.services.mozilla.com/D192755
We fail some because we right now we have a track pseudo for meter/progress.
I plan to fix this, but a lot of these frame classes are basically copy-pasta,
so I wanted to get rid of them first.
Differential Revision: https://phabricator.services.mozilla.com/D192097
This changes -moz-bool-pref from @supports to @media, bringing various
improvements:
* @media (-moz-bool-pref) properly reacts to dynamic changes.
* We no longer need to parse chrome:// stylesheets in the main thread
(-moz-bool-pref was the only thing that forced us to do that).
This makes privileged and non-privileged stylesheets more similar.
Differential Revision: https://phabricator.services.mozilla.com/D191196
This gives a significant windows sp3 improvement, without negatively
affecting memory usage much (on a preallocated content process I get
0.13mb of atoms both with and without this patch).
We could consider bumping it further to 1024, though the relative
improvement vs. this patch is small.
Differential Revision: https://phabricator.services.mozilla.com/D190692
See comment 0. This should avoid some lock contention, specially when
parsing CSS and other off-main-thread uses of atoms.
Differential Revision: https://phabricator.services.mozilla.com/D190408
Also make RemoveElementsAtUnsafe() private again because there are no
external callers. If any external callers are added, then we probably
want them to be made to a different version that does checks in
debug builds.
Differential Revision: https://phabricator.services.mozilla.com/D189557
Performance results pending, but this shouldn't hurt utf-8 atomization
at all, and it should also make utf-16 atomization potentially cheaper.
So sending for review under the assumption that perf numbers will look
good.
Differential Revision: https://phabricator.services.mozilla.com/D189021
Performance results pending, but this shouldn't hurt utf-8 atomization
at all, and it should also make utf-16 atomization potentially cheaper.
So sending for review under the assumption that perf numbers will look
good.
Differential Revision: https://phabricator.services.mozilla.com/D189021
The implementation is uglier than it needs to be. We basically need to
override the GTK styles for the window decorations with the desired
radius.
This is because of two reasons:
* Adwaita on gtk3 doesn't provide a bottom corner radius.
* Even if it did we couldn't reasonably query it, see comment 4.
So in order for stuff to look sensible we need to make sure that we and
GTK agree on what radius to use. Using the titlebar radius makes sense
here.
Differential Revision: https://phabricator.services.mozilla.com/D187343
Molly Howell
Jens Stutte
Adam Vandolder
Iulian Moraru
Emilio Cobos Álvarez
Vincent Hilla
Stanca Serban
Cosmin Sabou
Sylvestre Ledru
Sandor Molnar
Luke Warlow
keithamus
Olli Pettay
Cristina Horotan
Jan Varga
Andrew McCreight
Natalia Csoregi
Logan Rosen