Am 06.01.21 um 16:26 schrieb Michael Stahl:
On 06.01.21 14:56, Michael Meeks wrote:
Hi Julien,
On 18/12/2020 21:46, julien2412 wrote:
Gtk4 has been released 2 days ago, I know that migration from a
version to another version is not a 1 month work, but thought it
could be interesting and it can't hurt the current state of LO to
begin to prepare it by
Unfortunately the gtk+ team removed the GDK_THREADS annotation that
in conjunction with the gdk_threads_set_lock_functions method I
added back in 2003 is/was at the core of our ability to use gtk+
safely with threads and to share the SolarMutex with gtk+'s own
mutex.
Checkout:
https://bugzilla.gnome.org/show_bug.cgi?id=793124
[some ideas to workaround gtk+ GThread dropping]
hmm... isn't this basically the same situation as the macOS and the
Qt VCLplugs? they have a way to transfer widget work to the main
thread, see implementation of Qt5YieldMutex and osx/salinst.cxx
SalYieldMutex; this is all based on a design by jmux.
the relevant bug for Qt5 was about Wollmux extension calling from
non-main threads:
https://bugs.documentfoundation.org/show_bug.cgi?id=119856
This is all based on the Windows message passing stuff way older then my
implementations. While macOS and Qt pass a functor / std::function to
process in the main thread using some OS specifics, Windows just uses
messages to trigger stuff. Messages would be IMHO generally preferable,
if not for the SolarMutex hacks used on all platforms, because the main
thread then has to ignore the still locked SolarMutex in the other
thread, which is ... a big hack.
Am 06.01.21 um 16:26 schrieb Michael Stahl:
well i guess by "large apps" you mean LO, because hopefully nobody
else was dumb enough to f*ck up threading architecture in a GUI app
to the extent the StarOffice developers have.
AFAIK that was just the pre-2000s (1990s?) idea to do GUI with threads
in general and nothing LO specific (or so I was told). But if mmeeks
added this to gtk+, it might always just have been LO specific ;.)
The solution would be to simply give up on the whole idea, maybe even
getting rid of SolarMutex in the long term, at least to protect GUI changes.
Jan-Marek
P.S. and nowadays we have Vulkan, which introduced a threading API to
render stuff with multiple threads (/me likes the images in
https://developer.nvidia.com/sites/default/files/akamai/gameworks/blog/munich/mschott_vulkan_multi_threading.pdf).
But I doubt LO really needs this (or maybe someone want's to make a
"real" 3D LO GUI...)..
_______________________________________________
LibreOffice mailing list
LibreOffice@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/libreoffice
