[win32/c++/opengl] foute repaint scherm

[Krooswijk.com]

hoi ik heb het volgende probleem:

ik heb een zelfgemaakte (custom) windows control in een bepaalde test gui draaien. deze control geeft een opengl scene weer. nu zit ik met he volgende probleem. zodra ik uit de test gui bv een color choose dialog over de contol heen beweeg, blijft dat gedeelte van de control grijs. er wordt dus niet goed gerepaint.
ook als ik bv minimaliseer of een ander programma erover plaats, wordt de hele scene grijs. ik heb al geprobeerd om mijn update_scene functie in de WM_PAINT message van de control aan te roepen, maar tevergeefs. op deze manier heb ik het wel aand e gang gekregen, maar dan bij het "van de monitor" afschuiven van de test gui, worden alle overige interface elementen niet meer getekend.

als ik nu bv een message op de control afvuur, bv set_color_background( ) middels een color choose dialog , dan doe ik daarna direct een update_scene( ). dit werkt goed, alleen niet de eerste keer, na het verdwijnen van de color choose dialog blijft het gedeelte grijs, de keren daarna werkt alles goed.

iemand enig idee? komt het iemand bekend voor?

[hobbit_be]

lijkt me een InvalidateRect probleem

[curry684]

Je update_scene moet idd in de WM_PAINT plaatsvinden, en ik vermoed dat je de verkeerde WM_PAINT afvangt (form zelf) en vervolgens niet de DefWindowProc aanroept.

Zit je trouwens binnen een framework te werken of pure Win32?

[Krooswijk.com]

hobbit_be schreef op 09 July 2003 @ 19:13:
lijkt me een InvalidateRect probleem

ik kan het pas vrijdag testen, maar is het aan te raden een InvalidateRect te doen binnen een WM_PAINT, gaat het beeld daar niet van knipperen?

verder vang ik wel degelijk de WM_PAINT af van de control. maar ik doe het volgende:

C++:

case WM_PAINT:
{
    if( !my_control->update_scene( ) )  // my_control is huidige object
    {
        return( 0 );
    }

    break;
}

op deze manier wordt de DefWindowProc dus niet bereikt, aangezien bij een redraw altijd de scene opnieuw wordt getekend. waarom dient deze dan nog evt door te worden gestuurd naar de DefWindowProc?

wat bedoel je precies met een framework, ik heb een klasse model, opgebouwd in c++, maar alle gui zaken worden afgehandeld, middels win32. een setting op de control kan dus worden veranderd middels een SendMessage die een member functie aanroept, of door direct die member functie aan te roepen.

[Krooswijk.com]

het wil nog steeds niet werken, naast het bewegen van het scherm waardoor de overige gui elementen niet meer zichtbaar worden, worden ook choose color dialogs niet meer weergegeven.

niemand die dit probleem herkend?

[ Voor 76% gewijzigd door Krooswijk.com op 11-07-2003 15:03 ]

[curry684]

Ga eens wat docs lezen en dan specifiek die van de Win32 API calls BeginPaint en EndPaint en waarom je ze ABSOLUUT in je WM_PAINT handler moet plaatsen.

[curry684]

ps. check trouwens eens je CPU-load tijdens die 'vanhetschermschuif'-actie, ik gok op 100%. En je mag in principe InvalidateRect niet aanroepen tijdens een WM_PAINT handler (recursief en zo *duh*)

[Krooswijk.com]

ja invalidaterecten mag inderdaad niet, hij werkt nu goed met die paintstruct functies, en de cpu load wordt hooguit 20%

[curry684]

EndPaint zorgt voor het valideren van de rectangles. Als je die niet aanroept blijft het ding eindeloos repainten, vandaar 100% in dat geval.

En geen dank voor de hulp Koop anders een keer Petzold, goede investering

[Soultaker]

Dit wordt een heel erg off-topic reactie, maar het moet even!

curry684 schreef op 11 juli 2003 @ 17:33:
Koop anders een keer Petzold, goede investering

Ik vroeg me dus af om welk boek dat nou ging. Via via kwam ik uit op deze foto van mijnheer Petzold:


Is die man toegewijd of niet? Dat moest ik even kwijt.
_{Overigens zou ik Tux of Chuck leuker vinden als tatoo...}

[curry684]

Enge man, goed boek

Programming Windows 5th Edition is dus het boek in kwestie, aka de bijbel van Windows programmeren.

[Krooswijk.com]

curry684 schreef op 11 July 2003 @ 17:33:
EndPaint zorgt voor het valideren van de rectangles. Als je die niet aanroept blijft het ding eindeloos repainten, vandaar 100% in dat geval.

En geen dank voor de hulp Koop anders een keer Petzold, goede investering

uiteraard bedankt voor de hulp , en heb hier trouwens de 1e versie van petzold liggen, maar op de eoa manier altijd over dat hoofdstuk heengelezen...

[.oisyn]

je hele scene opnieuw renderen tijdens WM_PAINT is evil, en bovendien nogal nutteloos. Je gerenderde scene is er immers al, dus waarom alles opnieuw tekenen?

Ik neem aan dat je een doublebuffered device context gebruikt? Zo niet, ga dat eens snel doen, ketter! Een doublebuffered window heeft 2 pixelbuffers: de frontbuffer en de backbuffer. Het renderen gebeurt in de backbuffer. Zodra de scene klaar is, roep je SwapBuffers () aan, en de data in de backbuffer wordt dan gekopieerd naar de frontbuffer (die op het scherm zichtbaar is). De data in de backbuffer blijft daarbij onveranderd.

Goed, WM_PAINT wordt zoals je wellicht weet aangeroepen als een deel van een window opnieuw getekend moet worden. Een deel van de window op het scherm is dan weer zichtbaar geworden, zodat wat daar stond opnieuw opgebouwd moet worden. Dit is dus de frontbuffer die z'n data verloren is. De data moet dus vanuit de backbuffer opnieuw naar de frontbuffer gekopieerd worden, en dat kan simpelweg met een aanroep naar SwapBuffers ()

Je moet wel even opletten dat als je SwapBuffers () vanuit WM_PAINT aanroept je op dat moment niet naar de backbuffer aan het renderen bent. Is dat wel het geval dan kun je in principe gelijk retourneren vanuit WM_PAINT: de scene is dan zeer binnenkort klaar, waarna SwapBuffers () weer aangeroepen wordt.

curry: zegt Petzold ook iets over OpenGL?

[curry684]

Lijkt me niet dat je met een Windows-logo op je arm OpenGL gaat gebruiken ipv DirectX huh

Het hangt er ook vanaf hoe je de backbuffers gebruikt, als je deze discard tijdens de swap heb je er alsnog weinig aan, en zoals je al zegt zal de backbuffer vaak in-render troep bevatten. Net zo handig dus om een immediate render te forceren of gewoon terug te vallen indien bezig, backflip heb je imho niets aan.

[.oisyn]

Over dat windows-logo: opengl zit nou eenmaal in de platform SDK, dus...

Er staat nergens dat de contents worden gediscard, alleen dat er wordt gekopieerd

Microsoft's implementation of OpenGL inWindows NT/2000 and Windows 95/98 supports double buffering of images. This is a technique in which an application draws pixels to an off-screen buffer, and then, when that image is ready for display, copies the contents of the off-screen buffer to an on-screen buffer. Double buffering enables smooth image changes, which are especially important for animated images.

Two color buffers are available to applications that use double buffering: a front buffer and a back buffer. By default, drawing commands are directed to the back buffer (the off-screen buffer), while the front buffer is displayed on the screen. When the off-screen buffer is ready for display, you call SwapBuffers, and Windows NT/2000 and Windows 95/98 copies the contents of the off-screen buffer to the on-screen buffer.

En de backbuffer bevat geen in-render troep. Als je aan het renderen bent en er wordt ineens een WM_PAINT gegenereerd dan kun je die negeren: de scene is toch binnenkort klaar. Als je niet aan het renderen bent staat de scene klaar in de backbuffer en kun je die opnieuw transporteren met SwapBuffers ()