Generierung von WM_PAINT beeinflussen
-
Gibt es eine Möglichkeit zu beeinflussen für welches Fenster als erstes ein WM_PAINT synthetisiert wird wenn mehrere Fenster eine nicht leere Update-Region haben?
Grund warum ich frage ist, ich habe eine Anwendung wo mehrere Controls in einem Fenster "andauernd" neu gezeichnet werden sollen. Details auch hier nachzulesen: http://www.c-plusplus.net/forum/viewtopic-var-t-is-215324.htmlIch möchte nun dass immer das Fenster als erstes ein WM_PAINT bekommt welches schon am längsten nichtmehr dran war, bzw. schon am längsten darauf wartet neu gezeichnet zu werden. Windows nimmt aber anscheinend immer das erste Fenster welches es findet, und das führt dazu dass immer nur ein oder zwei Controls neu gezeichnet werden, die anderen kommen einfach nicht dran.
Im Prinzip habe ich bereits eine Lösung, allerdings eine sehr hässliche - steht auch im anderen Thread nachzulesen.
p.S.: falls es sich dabei um ein "Artefakt" des .NET Frameworks handeln sollte bitte ich um Aufklärung
Ich gehe erstmal davon aus dass da das .NET Framework sich auch nur darauf verlässt was Windows macht, und das in Windows allgemein für WM_PAINT so gelöst ist.
-
1. Wie kann es sein, dass ein Invalidate bereits wieder fälle, wenn ein Fenster gerade erst gezeichnet wurde.
2. In diesem Fall wurde ein forcieren mit RedrawWindow(...RDW_ALLCHILDREN...) helfen. Damit müsstest Du zumindest ein komplettes neuzeichnen erreichen.
3. Du arbeitest hoffentlich mit WS_CLIPCHILDREN und WS_CLIPSIBBLINGS!
4. Wird IMHO nicht das erste Fenster genommen, sondern das äußerste einer Hierachie (Parent zuerst)! Dann innerhalb der Children in der Z-Order, was auch genau der Doku entspricht, andernfalls wäre das Neuzeichnen nicht deterministisch.Was spricht also dagegen im besagten Parent z.B. RedrawWindow zu verwenden oder einfach alle Children mit einer Schleife ein UpdateWindow zu verpassen, wenn WM_PAINT im Parent ankommt.
Dann hast Du immer konstantes Verhalten ohne Tricks.
Lahm ist es dann immer noch.
-
ad 1: denk an Videos.
ad 2: siehe unten.
ad 3: keine Ahnung, .NET Framework Fenster -> muss ich nachgucken was da gesetzt ist.
ad 4: Ups, OK, Z-Order wird wohl stimmen. Ich hab' einfach nur beobachtet dass es halt immer ein bestimmtes Fenster ist(...)
Dann hast Du immer konstantes Verhalten ohne Tricks.
Lahm ist es dann immer noch.Jo bloss "steht" dann mein Programm weil es keine Input Messages mehr verarbeitet (Application Message > Input Message). Zumindest ist das das von mir beobachtete Verhalten bei UpdateWindow. RedrawWindow kann ich noch ausprobieren. Die Videos laufen natürlich noch, aber ich kann nichtmal das Fenster verschieben, geschweige denn irgendwas anderes damit machen.
-
Du darfst solch eine Technik also nicht verwenden. UpdateWindow frisst demnach alle Ressourcen und die Nachrichtenschleife kommt nicht nach bzw. gar nicht mehr dran.
Du musst also eine der Streaming Technologien verwenden mit denen bewegte Bilder angezeigt werden.
-
eine der Streaming Technologien
Nenne bitte zwei
BTW: DirectShow werde ich erstmal nicht verwenden. Das hat diverse Gründe. U.a. dass ich schonmal garkeinen Source-Filter habe, und auch keinen schreiben möchte. Und ich nicht 32 DirectShow Graphen in der Applikation haben möchte.
Und wieso sollte ich so eine Technik nicht verwenden dürfen? Bin ich jetzt der erste und einzige der mit WinAPI bewegte Bilder aufn Schirm zeichnen möchte? Und spielt es eine Rolle wo die Bilder herkommen? Würdest du jmd. der ein Grafikdemo schreibt auch sagen er soll "eine der Streaming Technologien" verwenden damit seine Bilder auf dem Schirm ankommen?
-
Bau Dir eine temporäre AVI
Wenn Du keine verwendest ist eben Dein Verfahren die Bilder anzuzeigen zu lahm...
Beschleunige das durch Caching oder wer weiß was!
-
Mit DrawDib kann man noch recht fix zeichnen (wenn man kein DX/DS/OpenGL nutzen will):
http://msdn.microsoft.com/en-us/library/ms708083(VS.85).aspx
-
DrawDib ist das was ich im Moment verwende, leider auch nicht gerade ein Ferrari. Und gleich schnell/langsam (+/- ein paar
wie StretchDIBits.
Trotzdem danke.
