From: Mathew Robertson (mathew.robertson_at_[hidden])
Date: 2004-12-23 18:56:39
> It's useful to be able to associate a "window" with a thread for
> high-performance GUI drawing. This is somewhat of a pain under Windows for
> legacy reasons but it's possible (I've done it within the context of the
> WTL). Here you simply blast the video subsystem with draw requests from
> multiple threads and place the onus of optimizing the call sequence on the
> driver and the underlying hardware. It would be useful to take this into
> account explicitly and build multithread support directly into the library.
> Placing the burden of this on the library user will invariably limit the
> portability of any application written against the lib I think.
Both, X and GDI are not thread safe (ie: a lot of the function calls are not re-enterent, and the globals variables are not locked)... you shouldn't do this...
You may however draw from multiple threads, provided that you manually serialise the GUI commands.
In reality you should have a single GUI thread, plus some worker threads - and this technique will be faster than multiple GUI-writers as you will only need to serialise when data needs to be accessed from the worker threads, as opposed to serialising for every draw.
FWIW, the underlying driver/hardware takes no part in 'threaded-ness capabilities', its X/GDI that you have to worry about, as it is that sub-system that crontrols what gets drawn.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk