http://bugs.winehq.org/show_bug.cgi?id=34889
Bug #: 34889 Summary: Drawing to device context outside message loop does not update window Product: Wine Version: 1.7.4 Platform: x86-64 OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: winex11.drv AssignedTo: wine-bugs@winehq.org ReportedBy: milasudril@gmail.com Classification: Unclassified
Created attachment 46495 --> http://bugs.winehq.org/attachment.cgi?id=46495 Source code demonstrating the issue.
When drawing to a window DC outside the message loop, the window does not update (see attachment).
On Windows: There is a flickering rectangle in the upper corner of the window On Wine: The rectangle is not affected until a message is posted from the system
Example compiled and tested with g++ 4.7.1 TDM-GCC 64 bit on Windows 7 64 bit. Compiler command:
g++ test.cpp -mwindows a.exe
http://bugs.winehq.org/show_bug.cgi?id=34889
milasudril@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |testcase
http://bugs.winehq.org/show_bug.cgi?id=34889
milasudril@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |milasudril@gmail.com
http://bugs.winehq.org/show_bug.cgi?id=34889
--- Comment #1 from Alexandre Julliard julliard@winehq.org 2013-11-10 14:17:58 CST --- Is there an actual application that has this problem?
http://bugs.winehq.org/show_bug.cgi?id=34889
--- Comment #2 from milasudril@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.
http://bugs.winehq.org/show_bug.cgi?id=34889
--- Comment #3 from Alexandre Julliard julliard@winehq.org 2013-11-12 02:41:50 CST --- That's not X limitations. The client-side rendering is flushed when the app processes messages. It would be possible to add extra flushing, but that would hurt performance for properly behaved apps, so I'm not going to do this unless there's a demonstrated need for it.
http://bugs.winehq.org/show_bug.cgi?id=34889
--- Comment #4 from milasudril@gmail.com 2013-11-12 10:52:08 CST --- Perhaps I should GdiFlush()
http://bugs.winehq.org/show_bug.cgi?id=34889
Jerome Leclanche adys.wh@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |RESOLVED Resolution|--- |WONTFIX
--- Comment #5 from Jerome Leclanche adys.wh@gmail.com --- Per AJ, WONTFIX.
https://bugs.winehq.org/show_bug.cgi?id=34889
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #6 from Austin English austinenglish@gmail.com --- Closing.