[Bug 34889] Drawing to device context outside message loop does not update window

[wine-bugs at winehq.org]

http://bugs.winehq.org/show_bug.cgi?id=34889

--- Comment #2 from milasudril at gmail.com 2013-11-12 01:32:21 CST ---
(In reply to comment #1)
> Is there an actual application that has this problem?

I use this technique because the way through InvalidateRect -> UpdateWindow ->
WM_PAINT is much slower than just drawing directly. It also separates control
from display in a natural way.

A more complete scenario is

 1. Create a window
 2. Get context of the window
 3. Start message loop. In this state, drawing is done through WM_PAINT
 4. User presses a "Start" button. A new program thread is started that checks
for a stop flag. If it is false, it issues commands that update the contents of
the window regularly without user interaction (spin OpenGL triangle if you
like). Meanwhile, the message loop checks for user input. Drawing may be issued
by WM_PAINT as well if the rendering is slow (or paused in case of a clock) but
drawing is fast.
 5. When user presses a "Stop" button the stop flag raises causing the
rendering thread to exit. Drawing is again issued by WM_PAINT

The reason of posting this bug is that I suspect limitations in X. For example,
GTK cannot do this.

-- 
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
Do not reply to this email, post in Bugzilla using the
above URL to reply.
------- You are receiving this mail because: -------
You are watching all bug changes.