The message queue in LayerTreeHostProxyQt is there because messages have to be processed in the correct order, and some of them require an active GL context (mainly the flush message). Instead of queuing everything until we're painting, we should be able to call something like makeContextCurrent() and handle those messages right away.
How it will work with paint thread without message queue? I was told, that threaded painting will become mandatory for qt5 soon.
(In reply to comment #1) > How it will work with paint thread without message queue? > I was told, that threaded painting will become mandatory for qt5 soon. Can we use locking instead of a message queue? The message queue was originally there for the GL context, not for threading.
In the first implementation I did, the message queue was there for threading, I'm not sure for the LayerTreeHostProxy case. Locking is not an option IMO if we eventually switch to threaded rendering.
r108951 Makes this not important, especially if we consider the comments about threaded rendering. The original motivation was to reduce the broilerplate code, but that's much better now.