View mode: basic / threaded / horizontal-split · Log in · Help
July 25, 2012
Multi-threaded GUI
Hi!

I'm trying to write a WinAPI example to have multi-threaded GUI. I wanna
have a Window class, which creates a window and listens to its messages in
a separate thread when constructed.  This will allow me to write a main
function like this:

void main()
{
   Window w = new Window;
   w.move(100, 200);
   w.resize(800, 600);
   w.show();
}

The methods called for the window will send asynchronous messages, which
will cause the window to change its position, size and visibility
on-the-fly. This is convenient, because no message loop needs to be
launched separately and every window will rocess its messages in a separate
thread.

Can anyone please tell me how to achieve this?

-- 
Bye,
Gor Gyolchanyan.
July 25, 2012
Re: Multi-threaded GUI
On 25/07/2012 19:34, Gor Gyolchanyan wrote:
> Hi!
>
> I'm trying to write a WinAPI example to have multi-threaded GUI. I wanna
> have a Window class, which creates a window and listens to its messages
> in a separate thread when constructed.  This will allow me to write a
> main function like this:
>
> void main()
> {
>      Window w = new Window;
>      w.move(100, 200);
>      w.resize(800, 600);
>      w.show();
> }
>
> The methods called for the window will send asynchronous messages, which
> will cause the window to change its position, size and visibility
> on-the-fly. This is convenient, because no message loop needs to be
> launched separately and every window will rocess its messages in a
> separate thread.
>
> Can anyone please tell me how to achieve this?
>
> --
> Bye,
> Gor Gyolchanyan.

It depends exactly on what you are trying to do, but in general:

You have to be very, very careful with trying to do multi threading w/ 
windoze windows. Try doing a google search on it, and the advice is 
invariably: don't do multi threaded windows. Everybody including people 
famous for their in-depth window knowledge recommends a single thread UI 
with non-UI worker threads.

Having completely separate top level windows each in it's own thread is 
ok, but if you want to have a parent/child relation between windows in 
different threads, then you can not use any thread synchronisation 
primitives all at other than MsgWaitForMultipleObjectsEx, otherwise you 
will have a guaranteed deadlock. In which case you'd have to do all of 
the threading your self and not use anything in phobos.

-- 
My enormous talent is exceeded only by my outrageous laziness.
http://www.ssTk.co.uk
July 25, 2012
Re: Multi-threaded GUI
On Wed, Jul 25, 2012 at 10:50 PM, Simon <s.d.hammett@gmail.com> wrote:

> On 25/07/2012 19:34, Gor Gyolchanyan wrote:
>
>> Hi!
>>
>> I'm trying to write a WinAPI example to have multi-threaded GUI. I wanna
>> have a Window class, which creates a window and listens to its messages
>> in a separate thread when constructed.  This will allow me to write a
>> main function like this:
>>
>> void main()
>> {
>>      Window w = new Window;
>>      w.move(100, 200);
>>      w.resize(800, 600);
>>      w.show();
>> }
>>
>> The methods called for the window will send asynchronous messages, which
>> will cause the window to change its position, size and visibility
>> on-the-fly. This is convenient, because no message loop needs to be
>> launched separately and every window will rocess its messages in a
>> separate thread.
>>
>> Can anyone please tell me how to achieve this?
>>
>> --
>> Bye,
>> Gor Gyolchanyan.
>>
>
> It depends exactly on what you are trying to do, but in general:
>
> You have to be very, very careful with trying to do multi threading w/
> windoze windows. Try doing a google search on it, and the advice is
> invariably: don't do multi threaded windows. Everybody including people
> famous for their in-depth window knowledge recommends a single thread UI
> with non-UI worker threads.
>
> Having completely separate top level windows each in it's own thread is
> ok, but if you want to have a parent/child relation between windows in
> different threads, then you can not use any thread synchronisation
> primitives all at other than MsgWaitForMultipleObjectsEx, otherwise you
> will have a guaranteed deadlock. In which case you'd have to do all of the
> threading your self and not use anything in phobos.
>
> --
> My enormous talent is exceeded only by my outrageous laziness.
> http://www.ssTk.co.uk
>
>
>
I see. Thanks for the reply. Somehow I suspected this to be the case.

-- 
Bye,
Gor Gyolchanyan.
July 25, 2012
Re: Multi-threaded GUI
On 25-Jul-12 22:34, Gor Gyolchanyan wrote:
> Hi!
>
> I'm trying to write a WinAPI example to have multi-threaded GUI. I wanna
> have a Window class, which creates a window and listens to its messages
> in a separate thread when constructed.  This will allow me to write a
> main function like this:
>
> void main()
> {
>      Window w = new Window;
>      w.move(100, 200);
>      w.resize(800, 600);
>      w.show();
> }
>
> The methods called for the window will send asynchronous messages, which
> will cause the window to change its position, size and visibility
> on-the-fly.

Use plain WinAPI SendMessage in all threads and one separate thread for 
GUI message pump.
In fact you can change shape and visibility of any window in a system. 
And you do not need to be superuser. Hence proliferation of locker type 
Trojans. Who told Windows is boring? ;)

>This is convenient, because no message loop needs to be
> launched separately and every window will rocess its messages in a
> separate thread.
>
> Can anyone please tell me how to achieve this?
>
The problem is that WinAPI event loop was created with single message 
pump per application. Hence problematic separation of window per thread.

Again that most straightforward (and effective) design is to use 1 
thread for all UI and a bunch of workers for other stuff and you are 
good to go.

Or, in your model, it looks like GUI is a background process, and 
workers rule it, interesting view esp w.r.t. user perspective :)

-- 
Dmitry Olshansky
July 25, 2012
Re: Multi-threaded GUI
On Wed, Jul 25, 2012 at 11:18 PM, Dmitry Olshansky <dmitry.olsh@gmail.com>wrote:

> On 25-Jul-12 22:34, Gor Gyolchanyan wrote:
>
>> Hi!
>>
>> I'm trying to write a WinAPI example to have multi-threaded GUI. I wanna
>> have a Window class, which creates a window and listens to its messages
>> in a separate thread when constructed.  This will allow me to write a
>> main function like this:
>>
>> void main()
>> {
>>      Window w = new Window;
>>      w.move(100, 200);
>>      w.resize(800, 600);
>>      w.show();
>> }
>>
>> The methods called for the window will send asynchronous messages, which
>> will cause the window to change its position, size and visibility
>> on-the-fly.
>>
>
> Use plain WinAPI SendMessage in all threads and one separate thread for
> GUI message pump.
> In fact you can change shape and visibility of any window in a system. And
> you do not need to be superuser. Hence proliferation of locker type
> Trojans. Who told Windows is boring? ;)
>
>
>  This is convenient, because no message loop needs to be
>> launched separately and every window will rocess its messages in a
>> separate thread.
>>
>> Can anyone please tell me how to achieve this?
>>
>>  The problem is that WinAPI event loop was created with single message
> pump per application. Hence problematic separation of window per thread.
>
> Again that most straightforward (and effective) design is to use 1 thread
> for all UI and a bunch of workers for other stuff and you are good to go.
>
> Or, in your model, it looks like GUI is a background process, and workers
> rule it, interesting view esp w.r.t. user perspective :)
>
> --
> Dmitry Olshansky
>

Yes. The idea was to programmatically operate on UI objects declaratively.
For instance, create a window, change its size, show it, draw on it and
never worry about "applying" (in the form of pumping the messages).

I guess the same effect can be achieved by having all windows created in a
separate thread and the message ump called in static ~this();

-- 
Bye,
Gor Gyolchanyan.
July 25, 2012
Re: Multi-threaded GUI
On Wednesday, 25 July 2012 at 18:50:51 UTC, Simon wrote:
> You have to be very, very careful with trying to do multi 
> threading w/ windoze windows. Try doing a google search on it, 
> and the advice is invariably: don't do multi threaded windows. 
> Everybody including people famous for their in-depth window 
> knowledge recommends a single thread UI with non-UI worker 
> threads.

Hmm... AFAIK it's quite opposite: windows UI is the only UI that 
works in multithreaded environment, it's just recommended to not 
do it, because this feature is inconsistent with other UI 
frameworks, so that you don't get used to wrong programming 
technique.
July 25, 2012
Re: Multi-threaded GUI
On Wednesday, 25 July 2012 at 19:25:09 UTC, Gor Gyolchanyan wrote:
> Yes. The idea was to programmatically operate on UI objects 
> declaratively.
> For instance, create a window, change its size, show it, draw 
> on it and
> never worry about "applying" (in the form of pumping the 
> messages).

Haha, show window and return from main.
July 26, 2012
Re: Multi-threaded GUI
On Wed, 2012-07-25 at 23:17 +0200, Kagamin wrote:
> On Wednesday, 25 July 2012 at 18:50:51 UTC, Simon wrote:
> > You have to be very, very careful with trying to do multi 
> > threading w/ windoze windows. Try doing a google search on it, 
> > and the advice is invariably: don't do multi threaded windows. 
> > Everybody including people famous for their in-depth window 
> > knowledge recommends a single thread UI with non-UI worker 
> > threads.
> 
> Hmm... AFAIK it's quite opposite: windows UI is the only UI that 
> works in multithreaded environment, it's just recommended to not 
> do it, because this feature is inconsistent with other UI 
> frameworks, so that you don't get used to wrong programming 
> technique.

I know essentially nothing of Windows, but quite a lot about
AWT/Swing/JavaFX/GroovyFX, GTK+2, GTK+3, PyGTK, PyGObject, PySide,
PyQt4, wxPython, and tkInter. As you say all of these use an
single-threaded event loop to manage all widgets. Fundamentally this is
because there is only one screen and one window manager, and all widgets
need to be manipulated relative to that. Using a single-threaded event
loop is the easiest way of avoid deadlock and livelock given that there
is a shared resource.

The same message has been learnt in Web servers where the multi-threaded
approach has given way to a single-threaded event loop approach.

So if Windows is really doing multi-threaded widget management, this
would be very interesting.  Where is the material that I can look at
that leads you to say that Windows is a multi-threaded UI.

As Simon mention, just because the UI is single-threaded doesn't mean
the application is. Exactly the opposite, good UI-based applications are
generally multi-threaded, it is just that there is only one thread
running the UI, all the others handle business logic.
-- 
Russel.
=============================================================================
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder@ekiga.net
41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel@winder.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder
July 26, 2012
Re: Multi-threaded GUI
On Thu, Jul 26, 2012 at 12:16 PM, Russel Winder <russel@winder.org.uk>wrote:

> On Wed, 2012-07-25 at 23:17 +0200, Kagamin wrote:
> > On Wednesday, 25 July 2012 at 18:50:51 UTC, Simon wrote:
> > > You have to be very, very careful with trying to do multi
> > > threading w/ windoze windows. Try doing a google search on it,
> > > and the advice is invariably: don't do multi threaded windows.
> > > Everybody including people famous for their in-depth window
> > > knowledge recommends a single thread UI with non-UI worker
> > > threads.
> >
> > Hmm... AFAIK it's quite opposite: windows UI is the only UI that
> > works in multithreaded environment, it's just recommended to not
> > do it, because this feature is inconsistent with other UI
> > frameworks, so that you don't get used to wrong programming
> > technique.
>
> I know essentially nothing of Windows, but quite a lot about
> AWT/Swing/JavaFX/GroovyFX, GTK+2, GTK+3, PyGTK, PyGObject, PySide,
> PyQt4, wxPython, and tkInter. As you say all of these use an
> single-threaded event loop to manage all widgets. Fundamentally this is
> because there is only one screen and one window manager, and all widgets
> need to be manipulated relative to that. Using a single-threaded event
> loop is the easiest way of avoid deadlock and livelock given that there
> is a shared resource.
>
> The same message has been learnt in Web servers where the multi-threaded
> approach has given way to a single-threaded event loop approach.
>
> So if Windows is really doing multi-threaded widget management, this
> would be very interesting.  Where is the material that I can look at
> that leads you to say that Windows is a multi-threaded UI.
>
> As Simon mention, just because the UI is single-threaded doesn't mean
> the application is. Exactly the opposite, good UI-based applications are
> generally multi-threaded, it is just that there is only one thread
> running the UI, all the others handle business logic.
> --
> Russel.
>
> =============================================================================
> Dr Russel Winder      t: +44 20 7585 2200   voip:
> sip:russel.winder@ekiga.net
> 41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel@winder.org.uk
> London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder
>

So the good way to do this will be to have a single thread, which pumps
messages and distributes the appropriate message handlers to worker
threads, right?

My goal here is to have 100% working and responsive GUI no matter how bad
the application lags. If, for instance, The user would push a button, which
initiates a very expensive computation, I don't want the GUI to become
stuck. If the user doesn't wait and pushes the button again, it should
display a message, which says "The operation is already in progress" or
something like that.

-- 
Bye,
Gor Gyolchanyan.
July 26, 2012
Re: Multi-threaded GUI
On Thu, 2012-07-26 at 13:45 +0400, Gor Gyolchanyan wrote:

> So the good way to do this will be to have a single thread, which pumps
> messages and distributes the appropriate message handlers to worker
> threads, right?
> 
> My goal here is to have 100% working and responsive GUI no matter how bad
> the application lags. If, for instance, The user would push a button, which
> initiates a very expensive computation, I don't want the GUI to become
> stuck. If the user doesn't wait and pushes the button again, it should
> display a message, which says "The operation is already in progress" or
> something like that.

Your goal is excellent. Throughout the early 2000s my staff had to
suffer the stupidities of software development environments that failed
to take this message on.

The "standard model" for doing this is for user event callbacks to
always act and if they need to do something that takes longer than a
very few instructions and/or takes more that a fraction of second (NB
user reaction time is around 0.2s, user boredom time is around 2s) spawn
a thread to undertake the work. If that then involves interaction, the
thread puts an event on the event queue and terminates.

Separation of concerns is also important here: no business logic in the
GUI code, no GUI code in the business logic. MVC (*), Mediator, Fa├žade,
are your friends.

(*) Microsoft's MVP variant of MVC is probably very appropriate on
Windows.
-- 
Russel.
=============================================================================
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder@ekiga.net
41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel@winder.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder
« First   ‹ Prev
1 2
Top | Discussion index | About this forum | D home