FlipBuffers() bleibt manchmal minutenlang hängen

[Kiffi]

hoere das mit dem schleifen zeug zum ersten mal

<klugscheiss>
ist ja auch keine Schleife. Ist 'ne Abfrage
</klugscheiss>

[xperience2003]

ist ja auch keine Schleife. Ist 'ne Abfrage

jo, hast recht

repeat
malewas
flipbuffers()
until lame=#true

in dieser abfrage gehts auch ^^

[Gimbly]

So, jetzt sind zweieinhalb Wochen vergangen und meine Lösung des WindowedScreen-Problems hat sich bewährt - keine Hänger mehr.

Ich denke, ich bin es PB und diesem Forum schuldig, ein Resümee zu ziehen.

Also, halten wir fest:

A) Eigentlich wäre es logisch (weil Ressourcen schonend), Flipbuffers() nur dann aufzurufen, wenn auf dem WindowedScreen etwas geändert wurde.
B) Allerdings führt ein sehr langes Nichtausführen von Flipbuffers() (weil der User z.B. eine Pause macht) manchmal dazu, dass der WindowedScreen beim erstmaligen Aufruf von Flipbuffers() nach der Pause nicht mehr reagiert und das Prog. hängen bleibt.
C) Darum sollte Flipbuffers() auch in Pausen regelmäßig aufgerufen werden, sagen wir mal mindestens einmal pro Sekunde, um ein "Einschlafen" (keine Ahnung, was sich da wirklich abspielt) des WindowedScreen zu verhindern.

Das Ganze habe ich unter Windows (XP u. Vista) beobachtet und nur beim WindowedScreen. Kann gut sein, dass es beim normalen Screen kein "Einschlafen" gibt.

Wer den Effekt unvoreingenommen (ohne: "hab ich ja noch nie gehört - gibt's nicht!") nachvollziehen möchte, kann das mit unten stehendem Beispielcode tun.
Einfach den Code starten und dann mal Esc drücken. Dann wird auf dem WindowedScreen "Esc wurde gedrückt" ausgegeben und nach einer Sek. wieder gelöscht. Das kann man dann einige Male wiederholen - funktioniert soweit.

Dann lässt man das Prog. offen und macht 10 oder 15 Minuten keine Eingabe (am besten im Hintergrund weiterlaufen lassen).

Wenn man dann das Prog. wieder in den Vordergrund holt und Esc drückt, passiert mit etwas "Glück" dann gar nichts. Das Prog. hängt und hat als letzte Aktion "kurz vor FlipBuffers()" in die Zwischenablage geschrieben (leicht zu überprüfen, indem man Strg-V in einem Editor drückt). Es hängt also bei Flipbuffers() und muss mit dem Taskmanager abgeschossen werden. Wenn das Prog. doch auf Esc reagiert, nochmals 10 bis 15 Min. warten und erneut probieren (habe den Eindruck, dass es unter Vista häufiger passiert, als unter XP). Manchmal dauert es auch über 1 Stunde, bis es hängt.

Code: Alles auswählen

InitSprite()
Breite=300 : Hoehe=200
  
OpenWindow(0,0,0,Breite,Hoehe,"Test",#PB_Window_SystemMenu|#PB_Window_ScreenCentered)
OpenWindowedScreen(WindowID(0),0,0,Breite,Hoehe,0,0,0)

AddKeyboardShortcut(0,#PB_Shortcut_Escape,#PB_Shortcut_Escape)

Repeat : Event=WaitWindowEvent()
  If Event=#PB_Event_Menu : Taste=EventMenu()
    If Taste=#PB_Shortcut_Escape

      StartDrawing(ScreenOutput())
      DrawingMode(#PB_2DDrawing_Transparent)
      DrawText(10,10,"Esc wurde gedrückt",RGB(255,0,0))  ;DrawStuff()
      StopDrawing()

      SetClipboardText("kurz vor FlipBuffers()"+Chr(10)) ;letzte Aktion vor dem Hänger
      FlipBuffers()   ;<================ hier hängt es
      SetClipboardText("nach FlipBuffers()"+Chr(10))

      Delay(1000)     ;1 Sek. warten
      ClearScreen(0)  ;und dann Screen wieder leeren
      FlipBuffers() 

    EndIf
  EndIf
Until Event=#PB_Event_CloseWindow

End

Diese Programmvariante funktioniert dagegen einwandfrei auch nach langen Pausen, weil dort auch in Pausen alle 100 Millisekunden FlipBuffers() aufgerufen wird.

Code: Alles auswählen

InitSprite()
Breite=300 : Hoehe=200
  
OpenWindow(0,0,0,Breite,Hoehe,"Test",#PB_Window_SystemMenu|#PB_Window_ScreenCentered)
OpenWindowedScreen(WindowID(0),0,0,Breite,Hoehe,0,0,0)

AddKeyboardShortcut(0,#PB_Shortcut_Escape,#PB_Shortcut_Escape)

Repeat : Event=WaitWindowEvent(100)
  If Event=#PB_Event_Menu : Taste=EventMenu()
    If Taste=#PB_Shortcut_Escape

      StartDrawing(ScreenOutput())
      DrawingMode(#PB_2DDrawing_Transparent)
      DrawText(10,10,"Esc wurde gedrückt",RGB(255,0,0))  ;DrawStuff()
      StopDrawing()

      SetClipboardText("kurz vor FlipBuffers()"+Chr(10)) ;letzte Aktion vor dem Hänger
      FlipBuffers()   ;<================ hier hängt es
      SetClipboardText("nach FlipBuffers()"+Chr(10))

      Delay(1000)     ;1 Sek. warten
      ClearScreen(0)  ;und dann Screen wieder leeren

    EndIf
  EndIf
  FlipBuffers() 
Until Event=#PB_Event_CloseWindow

End

Edit by NicTheQuick: STRG+C durch STRG+V ersetzt

[LCD]

Sorry dass ich mich als Nekrophiler betätigen muss, aber ich bin auf dasselbe Problem gestoßen als ich über einen WindowedScreen eine Messagebox mit Benchmarkergebnisen aufgerufen habe. Da Messagebox ja alles blockiert, kann ich auch nicht mit FlipBuffers() den screen refreshen, also wenn die MessageBox ein paar Minuten da steht, blockiert das Programm unweigerlich nach so ca. 15 Minuten.
Da ich die Informationen manchmal abschreiben und vergleichen will, ist es ein schwerer Bug. Inzwischen (gestern) habe ich sowieso alles vom Screen auf Image (Natürlich Memory Image mit POKEs) umgeschrieben, um überhaupt weiter arbeiten zu können.

IMHO könnte man das eigentlich ins Bug-Forum verschieben...

[Thorium]

Schonmal mit

Code: Alles auswählen

FlipBuffers(#PB_Screen_NoSynchronization)

probiert?
Ich weis nicht wie genau die Syncronisation intern funktioniert, aber auf jeden Fall wartet die Prozedur da. Vieleicht gibts da einen Bug, der halt bei langem nicht aufrufen zu Tage tritt.

[THEEX]

... dass ich mich als Nekrophiler betätigen muss, aber ich bin auf dasselbe Problem gestoßen als ich über einen WindowedScreen eine Messagebox mit Benchmarkergebnisen aufgerufen habe. Da Messagebox ja alles blockiert, kann ich auch nicht mit FlipBuffers() den screen refreshen, also wenn die MessageBox ein paar Minuten da steht, blockiert das Programm unweigerlich nach so ca. 15 Minuten.
Da ich die Informationen manchmal abschreiben und vergleichen will, ist es ein schwerer Bug.

Das ist in kein Bug, sondern einfach so gewollt. Die Messagebox soll das Programm anhalten. Sollte es nötig sein, daß eine Nachricht angezeigt wird, aber trotzdem ein weiterer Programmablauf nötig ist, kannst zB. eine eigene MessageBox bauen. Öffne ein kleines Fenster mit einem Textgadget, indem die Meldung angezeigt wird und mit einem oder mehreren Buttons zum bestätigen.

[Thorium]

Das ist in kein Bug, sondern einfach so gewollt. Die Messagebox soll das Programm anhalten. Sollte es nötig sein, daß eine Nachricht angezeigt wird, aber trotzdem ein weiterer Programmablauf nötig ist, kannst zB. eine eigene MessageBox bauen. Öffne ein kleines Fenster mit einem Textgadget, indem die Meldung angezeigt wird und mit einem oder mehreren Buttons zum bestätigen.

Ne, das ist ja nicht gemeint. Es geht darum das FlipBuffers das Programm anhält, nachdem die MessageBox geschlossen wurde.

[THEEX]

@Thorium

Da steht aber

Da Messagebox ja alles blockiert, kann ich auch nicht mit FlipBuffers() den screen refreshen, also wenn die MessageBox ein paar Minuten da steht, blockiert das Programm unweigerlich nach so ca. 15 Minuten

Das versteh ich aber anders....

[Thorium]

@Thorium

Da steht aber

Da Messagebox ja alles blockiert, kann ich auch nicht mit FlipBuffers() den screen refreshen, also wenn die MessageBox ein paar Minuten da steht, blockiert das Programm unweigerlich nach so ca. 15 Minuten

Das versteh ich aber anders....

Im Kontext zu diesem Thread ist es aber klar was er meint. Und zwar das, wenn die MessageBox ca. 15 Minuten offen bleibt, also die Programmausführung anhält, dann hängt sich FlipBuffers auf nach dem Schließen der MessageBox. Genau das gleiche Problem hatte ja der Threadersteller.

[LCD]

@Thorium

Da steht aber

Da Messagebox ja alles blockiert, kann ich auch nicht mit FlipBuffers() den screen refreshen, also wenn die MessageBox ein paar Minuten da steht, blockiert das Programm unweigerlich nach so ca. 15 Minuten

Das versteh ich aber anders....

Im Kontext zu diesem Thread ist es aber klar was er meint. Und zwar das, wenn die MessageBox ca. 15 Minuten offen bleibt, also die Programmausführung anhält, dann hängt sich FlipBuffers auf nach dem Schließen der MessageBox. Genau das gleiche Problem hatte ja der Threadersteller.

Exakt so ist es auch gemeint. Tut mir leid dass ich nicht dazugeschrieben habe dass das Programm erst blockiert nachdem ich zum normalen Programmablauf zurückkehren will, aber ich dachte dass das bei dem Thread klar ist. Also: Ich will die MessageBox nach ein paar Minuten schlieben und dabei blockiert sich das ganze Programm.
Auch SetTimer_() wird ja von MessageBox (und übrigens auch PopUp Menü) blockiert, so dass ich ihn nicht zum Aufrufen einer Routine und Screen Refresh auf Basis der Timer-Unterbrechungen nutzen kann (In der MultiThread-Programmierung bin ich noch nicht fit).
MessageBox verwende ich auch bei der neueren Version meines Programms (Wo ich jetzt direkt in den Speicher Poke wegen der 40-Fach höherer Geschwindigkeit gegenüber PLOT), und da blockiert das Programm nach dem schließen der Messagebox nicht, selbst wenn ich einige Stunden warte, Somit ist es weder beabsichtigt, noch ein Fehler meinerseits.
So ganz nebenbei, ich benutze sowieso FlipBuffers(0), was dem FlipBuffers(#PB_Screen_NoSynchronization) entspricht. Fürs Benchmark wären Syncs nicht gut, da Geschwindigkeit verlorengehen würden weil immer bis zum nächsten VerticalBlank gewartet wird (entspricht dem AMOS Befehl: Wait VBL).
Natürlich wartet keiner 15 Minuten nach dem öffnen eines PopUp Menüs um etwas daraus auszuwählen, aber bei MessageBox kann es sehr wohl passieren, und zwar regelmäßig.
Wenn ich eine eigene Messagebox baue, müsste ich die Abfragen direkt im Hauptprogramm durchführen (Alternativ in eigener Prozedur), solange die eigene Messagebox offen ist, und nebenbei die Buffers flipen. Etwas viel Aufwand um einen Bug zu umgehen.
Dieses Problem habe ich zumindest nicht bemerkt bei einer früherer Version die in PB 3.90 geschrieben war.