SFML 2.3 and GTK bug - related to XCB change

[foxbeard]

I was recently upgraded to SFML 2.3 and one of my SFML has issues with the new version.
I am seeing 2 separate issues, though I suspect the cause is related, so I am putting both in one post.

The program in question has an SFML OpenGL context embedded into a gtkmm windows. The SFML/gtkmm integration is based on a post from the wiki: https://github.com/SFML/SFML/wiki/Source%3A-GTK-SFMLWidget

1st, the OpenGL context is created without a depth buffer, stencil buffer, or antialiasing. It seems the sf::ContextSettings passed to sf::Window::create is ignored for embedded windows, and default to 0.

2nd, the context is not resized properly. When the window is resized, the SFML drawing area remains the same size, and the new space is left uninitialized/filled with garbage from the window resizing. I have verified that sf::Window::setSize is being called with the new size, but doesn't appear to be working.

The problem appears in v 2.3 and 2.3.1, but not in 2.2
I did a git bisect and narrowed the breaking commit to: https://github.com/SFML/SFML/commit/135c1716e877464db720265f37316cbb54ef13f2 This is a huge commit, and I haven't had time to look through the changes to see what in particular broke.

I have a trimmed down program that showcases the bug at: https://gist.github.com/mattvchandler/6f847d165e3abce7756d This requires SFML and gtkmm-3. It will dump the requested context settings and the context settings actually reported by sf::Window::getSettings. It sets the glClearColor to green and clears to make the resizing bug easy to see.

I am running Debian testing, up-to-date as of today, with gtkmm 3.16.

I also have the same program on windows, and SFML 2.3 does not have these issues on windows, so the problem is probably limited to linux. I don't have access to a mac to test on.

Thanks!

[binary1248]

1st, the OpenGL context is created without a depth buffer, stencil buffer, or antialiasing. It seems the sf::ContextSettings passed to sf::Window::create is ignored for embedded windows, and default to 0.

This was no different in SFML 2.2. Creating an SFML window from an existing window handle never changed it's visual settings. The difference lies in what this lead to. I guess in Xlib this meant that you got a context with the settings you expected, whereas in XCB you get a context with settings that you don't expect. Either way, I can look into whether the visual setting can be changed on already existing windows, although I can't promise this is even doable.

2nd, the context is not resized properly. When the window is resized, the SFML drawing area remains the same size, and the new space is left uninitialized/filled with garbage from the window resizing. I have verified that sf::Window::setSize is being called with the new size, but doesn't appear to be working.

I can't reproduce this. Resizing the window works for me, i.e. the drawing area changes size and is cleared to green as expected.

[victorlevasseur]

I can reproduce the same bug on Gnome 3.16.

[binary1248]

There are 2 issues, which one do you mean with "the same bug"?

[victorlevasseur]

Both.
I ran his example on Fedora 22 with Gnome/GTK 3.16.

[victorlevasseur]

Have you managed to reproduce the bug (it's a quite annoying one) ?

[binary1248]

No... can you upload a video of it or something?

[victorlevasseur]

Here are 2 screenshots to see the difference when we resize the window.

(I'm running on an recent Intel chipset, Optimus not enabled, never had problems with SFML before though).

EDIT : I've found a workaround consisting of recreating the window each time the widget is resized.

[binary1248]

Can you try drawing something to the render region? Clearing the background to green doesn't really help to understand the problem. Also, can you check to see if draw() is actually being called? SFML doesn't like it if widget toolkits like GTK only redraw when it thinks regions of the window are dirty.

[victorlevasseur]

Draw is called multiple times per second. So the problem doesn't seem to come from there.

By the way, when I resize the window, the view moves a bit : when resized in height, the view seems to be offset to the top by exactly the missing bottom part (watch the red rectangle in attachments). It doesn't happen for the width of the window.

[foxbeard]

Either way, I can look into whether the visual setting can be changed on already existing windows, although I can't promise this is even doable.

Bummer. I was able to work around the 1st problem by doing all of my rendering to a framebuffer object (where I could set my own depth buffer) and then blitting it back. I didn't notice any performance drop, so I can keep that for now.

EDIT : I've found a workaround consisting of recreating the window each time the widget is resized.

That is quite a workaround. I guess resize events aren't frequent enough to impact performance that much, though. I may give that a try.

Draw is called multiple times per second. So the problem doesn't seem to come from there.

By the way, when I resize the window, the view moves a bit : when resized in height, the view seems to be offset to the top by exactly the missing bottom part (watch the red rectangle in attachments). It doesn't happen for the width of the window.

Same here. Draw is being called; everything renders/animates correctly, and the view is being offset on vertical resize. See attached screenshot of my program. The sphere is centered in what should be the drawing area, but only the upper left portion of the screen can be drawn to, and the rest is filled with garbage. (multiple copies of the right sidebar, some other open windows, a bit of the taskbar, etc.)

I should have mentioned earlier: I'm running on an AMD APU chipset (Radeon HD 6209) using the open-source linux driver.

[binary1248]

Hmm... OK I can reproduce this issue, and I am pretty sure it has something to do with the horrible interaction between DRI2 and XCB for which there is already a hack in SFML. What complicates matters more is that now we have GTK in the picture as well, and who knows how X wire events get forwarded/handled by GTK windows. I'll try to come up with a fix for this, but it might take some time and might not even be possible if GTK doesn't cooperate.

[victorlevasseur]

Thanks for your help. 

(I really hope there's a fix because I have a app that relies a lot on this interaction)

[victorlevasseur]

Some news about this issue binary1248 ?

[binary1248]

GTK doesn't want to send us XCB events, so the only "fix" would be to revert back to Xlib event handling. There is no more hope with XCB, development is more or less abandoned and unless everybody switches over to using XCB like Qt did, software using differing libraries will not be compatible. If you can try to convince the rest of the team that switching back to Xlib handling is a good idea, then I will implement the fix in no time.