[5.22 LTS] WindowEvent() destroys graphics

[heartbone]

PB 5.22 LTS x86 Linux - UBUNTU 13.10

The title describes the bug.
Execute the code for a simple visual demonstration of the problem.

Graphics are created in a window, then a 3 second delay is forced on line 21.
You should change that Delay(3000) to observe the change in timing when the graphics destruction occurs.

After the delay, two variables are assigned values to control the triggering of a displayed message "AFTER 1 SECOND OF WindowEvent() CALLS".

After the delay and the two variables getting assigned, besides the WindowEvent() call, the only PureBasic code executing in the Repeat-Until loop during the one second when the graphics are destroyed, is the If test of the 2 control variables, and a Delay(2) call.
Of the code in that loop, I'm confident that it's the WindowEvent() call responsible for the damage, and the same result occurs with WaitWindowEvent().

This code works as expected in Windows, however it rarely runs the same way twice in Linux.

Code: Select all

Procedure RWB(X)
   StartDrawing(ScreenOutput())  
   DrawingFont(FontID(1)) 
   DrawText(X,200,"RED",RGB(255,0,0)) 
   DrawText(X,300,"WHITE",RGB(255,255,255))
   DrawText(X,400,"BLUE",RGB(0,0,255))
   StopDrawing() : FlipBuffers()
   Delay(500)
EndProcedure

LoadFont(1,"Arial",24,#PB_Font_Bold|#PB_Font_HighQuality)
LoadFont(2,"Arial",12,#PB_Font_Bold|#PB_Font_HighQuality)
If InitSprite()=0 : End : EndIf 
#FLAGS= #PB_Window_ScreenCentered|#PB_Window_MinimizeGadget
If OpenWindow(0,0,0,800,600,"SOFTWARE",#FLAGS)=0 : End : EndIf
If OpenWindowedScreen(WindowID(0),0,0,800,600,#True,0,0)=0 : End : EndIf
RWB(100) : RWB(200) : RWB(300) : RWB(400) : RWB(500)
StartDrawing(ScreenOutput()) : DrawingFont(FontID(2)) 
DrawText(150,500,"NOW A 3 SECOND DELAY BEFORE CALLING WindowEvent()",RGB(192,192,0)) 
StopDrawing() : FlipBuffers()
Delay(3000)
DRAWFLAG= 1
DRAWTIME= ElapsedMilliseconds()+1000
Repeat
   If DRAWFLAG And DRAWTIME < ElapsedMilliseconds()
      DRAWFLAG= 0
      StartDrawing(ScreenOutput()) : DrawingFont(FontID(2)) 
      DrawText(150,550,"AFTER 1 SECOND OF WindowEvent() CALLS",RGB(192,192,0)) 
      StopDrawing() : FlipBuffers()      
   EndIf
   Delay(2)
Until WindowEvent()= #PB_Event_CloseWindow
End

I made the RWB(x) procedure and called it 5 times (only changing the xposition parameter) to demonstrate how this simple and small procedure in Linux can produce inconsistent and glitchy results is such a simple program environment.
Obviously that glitchiness represents a separate bug, however I am at a loss how to define it, other than it glitches.
If the glitches happen for others, then perhaps another member with a better handle on this style of problem will submit a report detailing the bad behaviour.

** Based on the contents of this post, there may be some graphics problems specific to the 13.10 version of UBUNTU. **

The graphics glitches seem to be lessened when I run a compiled executable and I just ran a compiled version of the code above on a 13.04 (Raring Ringtail) x86 installation. Those semi random graphical glitches that are produced by the RWB() procedure calls on my system were not there.

However the graphics destruction error persisted.
My best guess as to the cause of the graphics destruction, is that something is interfering with the double buffering process.

[Fred]

Your event loop is wrong, you need to process all the events at each frame, as stated in the doc:

http://www.purebasic.com/documentation/ ... creen.html

All the events needs to be processed before flipping the buffers (see the examples below).

Correct pseudo code:

Code: Select all

Repeat
    ; It's very important to process all the events remaining in the queue at each frame
    ;
    Repeat
      Event = WindowEvent()
      
      Select Event 
        Case #PB_Event_Gadget
          If EventGadget() = 0
            End
          EndIf
        
        Case #PB_Event_CloseWindow
          End 
      EndSelect
    Until Event = 0
  
    FlipBuffers() 
  ForEver

[heartbone]

Your event loop is wrong, you need to process all the events at each frame, as stated in the doc:
http://www.purebasic.com/documentation/ ... creen.html

Thanks for taking the time to debug this bug. I will try to make it work in my project a bit later today, after a job interview.

All the events needs to be processed before flipping the buffers (see the examples below).

I missed that quote in the command documentation. If I had known about it, I certainly would have not made the mistake and would have saved hours of wasted effort.
For sure that information NEEDS to be put into the language documentation in a logical place,
the FlipBuffers()]command,
since the bad graphics effects of not clearing the event queue are not apparent in Windows.

I am curious, do you understand why the FlipBuffers() command works as expected in Windows fine without the clearing of the queue?

[luis]

... I would like to locate it.

It's in the page linked above, in the OpenWindowedScreen() command.

[heartbone]

It's in the page linked above, in the OpenWindowedScreen() command.

Thanks luis. You are too fast and beat me to the punch.
I took the brute force method and searched the Language Command PDF to find the quote buried in that description for OpenWindowedScreen.
I suppose that after another couple of years of hacking around I'll get used to today's complicated programming environment and know the gotchas.

[heartbone]

OK I made the advised changes and it is not much improvement on the graphics destruction,
the executing code still acts up in both my Saucy UBUNTU systems.
With the changes, only the first column of RED WHITE BLUE is getting destroyed, and the glitching is reduced..
Frustratingly weird.
I dearly hope that programmer error is not the culprit this time.
Is it PB or UBUNTU?
It might be UBUNTU because the same code bugs out differently in 13.10 vs 13.04.
I get a white background replacing the missing column in 13.10, whereas I get a black one in 13.04 from the same binary.
Then sometimes I can run the code from the IDE and it works perfectly, so I create an executable and run it and it's still flaky, so I go back in to the same IDE session with the same code in the window and run it and the first column gets overwritten by a white background again.

Code: Select all

Procedure RWB(X)
   StartDrawing(ScreenOutput())  
   DrawingFont(FontID(1)) 
   DrawText(X,200,"RED",RGB(255,0,0)) 
   DrawText(X,300,"WHITE",RGB(255,255,255))
   DrawText(X,400,"BLUE",RGB(0,0,255))
   StopDrawing() : While WindowEvent() : Wend  : FlipBuffers()
   Delay(500)
EndProcedure

LoadFont(1,"Arial",24,#PB_Font_Bold|#PB_Font_HighQuality)
LoadFont(2,"Arial",12,#PB_Font_Bold|#PB_Font_HighQuality)
If InitSprite()=0 : End : EndIf 
#FLAGS= #PB_Window_ScreenCentered|#PB_Window_MinimizeGadget
If OpenWindow(0,0,0,800,600,"SOFTWARE",#FLAGS)=0 : End : EndIf
If OpenWindowedScreen(WindowID(0),0,0,800,600,#True,0,0)=0 : End : EndIf
RWB(100) : RWB(200) : RWB(300) : RWB(400) : RWB(500)
StartDrawing(ScreenOutput()) : DrawingFont(FontID(2)) 
DrawText(150,500,"NOW A 3 SECOND DELAY BEFORE CALLING WindowEvent()",RGB(192,192,0)) 
StopDrawing() : While WindowEvent() : Wend  : FlipBuffers()
Delay(3000)
DRAWFLAG= 1
DRAWTIME= ElapsedMilliseconds()+1000
Repeat
   If DRAWFLAG And DRAWTIME < ElapsedMilliseconds()
      DRAWFLAG= 0
      StartDrawing(ScreenOutput()) : DrawingFont(FontID(2)) 
      DrawText(150,550,"AFTER 1 SECOND OF WindowEvent() CALLS",RGB(192,192,0)) 
      StopDrawing() : While WindowEvent() : Wend : FlipBuffers()      
   EndIf
   Delay(2)
Until WindowEvent()= #PB_Event_CloseWindow
End

Unless someone can point me to a version of Linux where this simple program will work as it does in Windows, it is becoming apparent that I must develop in Windows in order to get results.
I wanted to use Linux to build and release a small two or three week project that I'm constructing along with my children, to start teaching them a little programming.

Even though it seems that Wine can't process my project's full screen mode, it handles the WindowedScreen mode in the windows executable built from the project's source.
Sadly Wine may end up being the only way to access our little application from the Linux that we love to use more and more over time.
I sincerely hope this is an UBUNTU OS and not PB compiler problem or dumb programmer problem, and all that I have to do is switch the OS to build correctly working executables. That I can fix.

[heartbone]

I am not going to submit a seperate bug report for what I am about to describe because I do believe that it is proper to consider the problem to originate from the WindowsEvent() call.

During that three second delay before the windows event call, click the window's title bar and give the window a move.

That is another WindowEvent() graphics destruction bug that can be reliably repeated on my systems.

[heartbone]

No hate Fred, only love.
I know that you do top quality work.
Linux is what it is, and you are only one man.
Sincere thanks.
Peace.

[luis]

During that three second delay before the windows event call, click the window's title bar and give the window a move.

I have some notes/suggestions:

1) You are better off not using that "While WindowEvent() : Wend" even if it's often saw in the forum (can be ok for a quick fix or to confirm a problem, but not to really use it).

When you do so you are trying to coerce event programming to MSDOS style programming.
The message processing should be:

a) continuous
b) not spread around the code, but kept in one place unless you really thought well about what you are doing

You are sooner or later not processing messages that way, or process them too late to keep the UI working as it should.
When you exit the ""While WindowEvent() : Wend" there is no guarantee another message it's just in need to be processed.
Was not in queue one instant ago but it can be now. And who knows when you will process or at least remove it from the queue.

So when you see graphic/gui glitch in a program written like the ones you written above, there is no way to be sure there is a bug in PB, until you write a proper message loop.

2) Same thing goes with all the delay() you are putting around. This was ok in MSDOS. It's not ok now.

Every delay stop the execution flow, everything is dead for that time and messages are piling up.
You should use another approach if you want to time gui updates, use the continuous loop and keep track of the passing time inside the loop and fire the updates from there, or use a timer.

For example:

Code: Select all

 Procedure RWB(X)
   StartDrawing(ScreenOutput()) 
   DrawingFont(FontID(1))
   DrawText(X,200,"RED",RGB(255,0,0))
   DrawText(X,300,"WHITE",RGB(255,255,255))
   DrawText(X,400,"BLUE",RGB(0,0,255))
   StopDrawing()
EndProcedure

LoadFont(1,"Arial",24,#PB_Font_Bold|#PB_Font_HighQuality)
LoadFont(2,"Arial",12,#PB_Font_Bold|#PB_Font_HighQuality)
If InitSprite()=0 : End : EndIf
#FLAGS= #PB_Window_ScreenCentered|#PB_Window_MinimizeGadget
If OpenWindow(0,0,0,800,600,"SOFTWARE",#FLAGS)=0 : End : EndIf
If OpenWindowedScreen(WindowID(0),0,0,800,600,#True,0,0)=0 : End : EndIf

AddWindowTimer(0, 1, 500)

count = 0

Repeat
    
    Repeat
        Event = WindowEvent()
     
        Select Event
                
            Case #PB_Event_Timer            
                If And EventTimer() = 1
                    count + 1
                    If count <= 5
                        RWB(count * 100)        
                    Else
                        RemoveWindowTimer(0, 1)
                    EndIf
                EndIf    
       
            Case #PB_Event_CloseWindow
                End

        EndSelect

    Until Event = 0
    
    FlipBuffers()    
    
    Delay(16)
    
ForEver 
  

3) A PB screen is for games and should be refreshed every frame or at least often if you are using it in accumulation mode (not clearing it between updates).
The fact you move the window and contents are destroyed can happen, maybe not on all platforms but definitively on some.
That could maybe be avoided by PB (maybe) but in any case you should not count on it. Resizing / moving the window could destroy the graphics contents so you should repaint them.
Same thing when using WindowOutput().

Probably you could use a canvas gadget instead of a screen, or an image associated to one imagegadget.Those are guaranteed (if I'm not mistaken) to keep their contents even without the need of refresh them.
Something like this:

Code: Select all

 Procedure RWB(X)
   StartDrawing(CanvasOutput(1)) 
   DrawingFont(FontID(1))
   DrawText(X,200,"RED",RGB(255,0,0))
   DrawText(X,300,"WHITE",RGB(255,255,255))
   DrawText(X,400,"BLUE",RGB(0,0,255))
   StopDrawing()
EndProcedure

LoadFont(1,"Arial",24,#PB_Font_Bold|#PB_Font_HighQuality)
LoadFont(2,"Arial",12,#PB_Font_Bold|#PB_Font_HighQuality)
;;; If InitSprite()=0 : End : EndIf
#FLAGS= #PB_Window_ScreenCentered|#PB_Window_MinimizeGadget
If OpenWindow(0,0,0,800,600,"SOFTWARE",#FLAGS)=0 : End : EndIf
CanvasGadget(1, 0, 0, 800, 600)
StartDrawing(CanvasOutput(1)) 
Box(0,0,800,600, 0)
StopDrawing()
;;; If OpenWindowedScreen(WindowID(0),0,0,800,600,#True,0,0)=0 : End : EndIf

AddWindowTimer(0, 1, 500)

count = 0

Repeat
    
    Repeat
        Event = WindowEvent()
     
        Select Event
                
            Case #PB_Event_Timer            
                If And EventTimer() = 1
                    count + 1
                    If count <= 5
                        RWB(count * 100)                        
                    Else
                        RemoveWindowTimer(0, 1)
                    EndIf
                EndIf    
       
            Case #PB_Event_CloseWindow
                End

        EndSelect

    Until Event = 0
    
    ;;; FlipBuffers()    
    
    Delay(16)
    
ForEver 
  

Using this approach you can also probably change WindowEvent() to WaitWindowEvent() and loop only when messages are coming.

Anyway, the main point is: MSDOS <> event driven programming, MSDOS style will give you only problems (there are ways to do it properly using a couple of threads, but that's beyond the point now). I suggest you to rethink your program layout.

[heartbone]

Thanks for the thinking about my problems and the recommendation contribution luis.

I normally do not have need to use the Delay() function in my programs for much of anything
so please do not correlate the use here to my style of coding.
It was used here to illustrate the problem,
but I do get your point that (ab)using it will cause problems with the event processing.

Although I've never programmed MSDOS code, again I do get your meaning about the old style programming where processing these events was unnecessary.
I wish that they could be turned off in the curent PB windowed environment if not being used (just like it is in the PB OpenScreen() environment), but apparently they are a necessary headache when running PB code within in a window.
I normally do keep that processing in a central place and not spread around the code as you recommend.

Code: Select all

Procedure CLEARQUEUE()
; Empties xevent queue
   While WindowEvent() : Wend 
Endprocedure

In this case to better show the modifications to Fred, I declined to introduce yet another Procedure into my example code.

So if the recommended way to clear the queue is not correct, then what to use?
In my current program I have absolutely no use for any of the queued events except the close window signal.

Additionally these specific problems are not related to the old style programming since
1) the commands work as documented and as expected in Windows,
2) I followed all the programming rules and was still able to demonstrate the Linux problems.

If Delay() is no longer a valid function to use in Windowed PB code, as you seem to indicate, then that should be made known.
Perhaps there is a time limit threshhold based on environmental factors?
As far as I know, using those Delay(500) in this example is valid code, yet you assert it possibly could be part of the problem!!!

Again luis, thanks a lot for trying to teach this old dog some new tricks.
I will study your code to figure out what deep magic you are doing.
And yes, the graphics still get destroyed when moving a window on my system.

[luis]

I can discuss only the code posted here

1) they work as expected in Windows,

Code can work in windows and not in linux, but not "as expected". I wouldn't expect code like the above to work flawlessly on any platform, if it does nice, but it's not the way to structure it in my opinion.
Again, to be sure there is a bug in PB, the test code need to be restyled to exclude other possible factors.

2) I followed the rules to demonstrate the problems.

I wouldn't say that. You extracted the messages, at some arbitrary points, along the flow of your code. You didn't do it in a seamless way.
That can be ok, or can't be. It's not the proper way in my opinion, and I don't think it can be reliably used to determine if indeed a bug is present. See the point above. It's not a clean scenario for a test code demonstrating a bug.

If Delay() is no longer a valid function to use in Windowed PB code, as you seem to indicate, then that should be made known.

I didn't. It can be used when it's ok to use it. For example I've used in the code I've posted, to limit the FPS to 60 (or better in this case it's the number of loops per second) and reduce CPU hogging since we were using WindowEvent() instead of WaitWindowEvent().
But you used in the bulk of your timing to delay the update of the gui 500 ms at a time. I've totally get rid of that using a timer and processing the messages for the whole 2500 ms when you frozen the code for 2500 ms.

And there are the other points I've mentioned about the less troublesome way to use a PB screen (refresh it more often and when something "dimensional/positional" change).

And yes, the graphics still get destroyed when moving a window on my system.

With both the codes above ? I can understand with the PB screen, but with the canvas I think it should work (but I admit I'm not sure even if I believe the canvasgadget is persistent as the imagegadget, works in my Linux Mint VM). Definitively should work using an imagegadget anyway. If not, then probably it's a bug.

[heartbone]

And yes, the graphics still get destroyed when moving a window on my system.

With both the codes above ? I can understand with the PB screen, but with the canvas I think it should work (but I admit I'm not sure even if I believe the canvasgadget is persistent as the imagegadget, works in my Linux Mint VM). Definitively should work using an imagegadget anyway. If not, then probably it's a bug.

No not with both, I am sorry about that miscommunication.
Your canvas gadget code works perfectly and seems like a good solution for that window move graphics update problem.

As far as your suggested code restructuring to properly process the unused windows events... it seems like a lot.
It very well may mean that I will need two significantly different modes of processing, one for windowed and one for full screen.
because none of this event processing will ever happen in the full screen mode.
Also these changes are totally unecessary to be implemented for the Windows programs to function just fine.
So it seems that this restructuring is only needed for windowed programs running in Linux.
Now I must figure out what you did to make it work in Linux, and do I want to make the effort to adapt quickly or slowly.
Thanks a lot for the help luis.

[luis]

Just keep in mind if you want to use the pb screen instead of the canvas gadget, I wouldn't use the "accumulation mode", because if the contents are destroyed by resize or movement, you need to refresh the whole content.
So I would use the traditional gaming approach, regenerate the full screen contents on every update.
In windowed mode yes you have some messages to process, but it's not difficult to differentiate, just use the windowed mode loop structure for both and use a MyWindowEvent() wrapping the real one. In full screen your wrapper will just return 0 (no messages pending) and all will work automagically.

This is a just a way, the possible approaches are endless just take your time and build a small test framework to fine tuning it.

If you use the canvas, there is not full screen mode, but you can use a "full desktop mode" (a big window sized as the desktop, borderless) so in that case processing message it's the same in windowed or desktop mode.

Have fun

[heartbone]

Just keep in mind if you want to use the pb screen instead of the canvas gadget, I wouldn't use the "accumulation mode", because if the contents are destroyed by resize or movement, you need to refresh the whole content.
So I would use the traditional gaming approach, regenerate the full screen contents on every update.
In windowed mode yes you have some messages to process, but it's not difficult to differentiate, just use the windowed mode loop structure for both and use a MyWindowEvent() wrapping the real one. In full screen your wrapper will just return 0 (no messages pending) and all will work automagically.

This is a just a way, the possible approaches are endless just take your time and build a small test framework to fine tuning it.

If you use the canvas, there is not full screen mode, but you can use a "full desktop mode" (a big window sized as the desktop, borderless) so in that case processing message it's the same in windowed or desktop mode.

Compiled in Windows the code below works just fine, but apparently full screen rendering to the PureBasic screen from Linux is IMPOSSIBLE for me at this time based on my limited knowledge.

Code: Select all

LoadFont(1,"Arial",20,#PB_Font_Bold|#PB_Font_HighQuality)
If InitSprite()=0 : End : EndIf  
If OpenScreen(800,600,32," ")=0 : End : EndIf
StartDrawing(ScreenOutput())
DrawingFont(FontID(1))
DrawText(200,300,"YELLOW TEXT for 5 seconds",RGB(200,200,0))
StopDrawing() 
FlipBuffers()
Delay(5000)
End

So rendering to that recommended canvas gadget is looking better and better all the time.
I will first build my project using my old school simple screen methods on Windows so it will be easier for my kids to comprehend.
Then I'll port it to Linux using your suggested event wrapper strategy and canvas gadget.

Thanks again luis for the excellent ideas and expert help, as a result perhaps eventually I will be able to fashion a suitable Linux executable.

[luis]

That simple code should work AFAIK (maybe you could try 24 instead of 32 for BPP).
It works in my Linux VM, nothing wrong with that.
What's the problem you experienced ?
Anyway with the canvas it's a lot more difficult to encounter compatibility problems, opening a full screen, considering all the linux distributions and all the possible different version of libraries involved it's a more delicate operation