About preparing migration towards gtk4

[Jan-Marek Glogowski]

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...)..