Welcome, Guest. Please login or register. Did you miss your activation email?

Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - foxbeard

Pages: [1]
1
General / Re: SFML 2.3 and GTK bug - related to XCB change
« on: July 13, 2015, 05:04:09 pm »
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.

2
General / SFML 2.3 and GTK bug - related to XCB change
« on: July 10, 2015, 01:05:09 am »
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!

Pages: [1]
anything