OpenGL window shows stuff from background windows instead of blank window - c++

Question

I am using Linux and trying to learn OpenGL. I am refering to the website learnopengl.com and have compiled the first program available here.
I seem to compile the program without problem with he command
g++ -Wall -lGLEW -lglfw -lGL -lX11 -lpthread -lXrandr -lXi ./foo.cpp
But when I run the program it shows stuff from behind, instead of blank window, like this
Note however, that this window is not transparent, as in if I move the window, the background is same. But if I minimize and reopen the window, the background is newly created. This happens for both dedicated and integrated GPU.
What do I need to do to make it work properly?
Here is some info
System: Host: aditya-pc Kernel: 4.4.13-1-MANJARO x86_64 (64 bit gcc: 6.1.1)
Desktop: KDE Plasma 5.6.4 (Qt 5.6.0) Distro: Manjaro Linux
Machine: System: HP (portable) product: HP Notebook v: Type1ProductConfigId
Mobo: HP model: 8136 v: 31.36
Bios: Insyde v: F.1F date: 01/18/2016
CPU: Dual core Intel Core i5-6200U (-HT-MCP-) cache: 3072 KB
flags: (lm nx sse sse2 sse3 sse4_1 sse4_2 ssse3 vmx) bmips: 9603
clock speeds: max: 2800 MHz 1: 583 MHz 2: 510 MHz 3: 670 MHz 4: 683 MHz
Graphics: Card-1: Intel Skylake Integrated Graphics bus-ID: 00:02.0
Card-2: Advanced Micro Devices [AMD/ATI] Sun XT [Radeon HD 8670A/8670M/8690M / R5 M330]
bus-ID: 01:00.0
Display Server: X.Org 1.17.4 drivers: ati,radeon,intel
Resolution: 1920x1080#60.06hz
GLX Renderer: Mesa DRI Intel HD Graphics 520 (Skylake GT2)
GLX Version: 3.0 Mesa 11.2.2 Direct Rendering: Yes
The two graphics card's info
Amd card
$ DRI_PRIME=1 glxinfo|grep OpenGL
OpenGL vendor string: X.Org
OpenGL renderer string: Gallium 0.4 on AMD HAINAN (DRM 2.43.0, LLVM 3.8.0)
OpenGL core profile version string: 4.1 (Core Profile) Mesa 11.2.2
OpenGL core profile shading language version string: 4.10
OpenGL core profile context flags: (none)
OpenGL core profile profile mask: core profile
OpenGL core profile extensions:
OpenGL version string: 3.0 Mesa 11.2.2
OpenGL shading language version string: 1.30
OpenGL context flags: (none)
OpenGL extensions:
OpenGL ES profile version string: OpenGL ES 3.0 Mesa 11.2.2
OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.00
OpenGL ES profile extensions:
Intel integrated
$ DRI_PRIME=0 glxinfo|grep OpenGL
OpenGL vendor string: Intel Open Source Technology Center
OpenGL renderer string: Mesa DRI Intel(R) HD Graphics 520 (Skylake GT2)
OpenGL core profile version string: 3.3 (Core Profile) Mesa 11.2.2
OpenGL core profile shading language version string: 3.30
OpenGL core profile context flags: (none)
OpenGL core profile profile mask: core profile
OpenGL core profile extensions:
OpenGL version string: 3.0 Mesa 11.2.2
OpenGL shading language version string: 1.30
OpenGL context flags: (none)
OpenGL extensions:
OpenGL ES profile version string: OpenGL ES 3.1 Mesa 11.2.2
OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.10
OpenGL ES profile extensions:

Answer 1

Technically what you experience is undefined behaviour. So here's what's happening: Your program asks the graphics system to create a new window and because this window is going to be used with OpenGL the library you're using (GLFW) is asking the graphics system to not clear the window on its own (the reason for this is that when playing animations the graphics system clearing the window between frame draws will cause flicker, which is unwanted).
So that new window is created and it needs graphics memory for doing that. These days there are two ways at presenting a window to the user. One is off-screen rendering with on-screen composition. The other is on-screen framebuffer windowing with pixel ownership testing. In your case you're getting the later of the two. Which means your window is essentially just a rectangle in the main screen framebuffer and when it gets created new, whatever was there before will remain in the window until it gets drawn with the desired contents.
Of course this "pixels left behind" behaviour is specified nowhere, it's an artifact of how the most reasonable implementation behaves (it behaves the same on Microsoft Windows with Areo disabled).
What is specified is, that when a window gets moved around its contents are moved along with it. Graphics hardware, even as old as from the late 1980-ies has special circuitry built in to do this efficiently. But this works only for as long as the window stays within the screen framebuffer. If you drag the window partially outside of the screen area and back again you'll see the border pixels getting replicated along the edges.
So what do you have to do to get a defined result? Well, you'll have to actually draw something (might be as simple as clearing it) to the window – and if it's a double buffered one swap the buffers.