SFML as a subview

[j.keller51]

I'm using SFML in a plug-in environment, e.g. a host application gives me a window and I have to make the SFML window a child of that window.

In Windows, this "just works" and I haven't had issues.

On OSX, I've had to make a couple of patches:

1. Resizing
I encountered weird behavior where the drawing area was resized incorrectly while "live resizing" the NSWindow.

If the window width before the resize operation began was x, and the current window width while resizing is x' = x + dx, then you would expect the SFML drawing width to also be x' = x + dx. Instead, it is x + 2*dx. This applies for expanding and contracting the window. The same applies for the y axis.

Illustration of this:


Weirdly, when contracting, the empty area is filled by the SFML window's background color, whatever that is set to.

As soon as the mouse is released, the SFML drawing area snaps back to the correct size.

The fix I came up with was, in src/SFML/Window/OSX/SFOpenGLView.mm:

Change

-(void)update
{
    // In order to prevent an infinite recursion when the window/view is
    // resized to zero-height/width, we ignore update event when resizing.
    if (![self inLiveResize]) {
        [super update];
    }
}

to

-(void)update
{
    [super update];
}
 

This made the window resizing behave as expected.

Obviously, the inLiveResize check was supposed to be doing something important, so maybe just taking it out isn't a good long-term solution. Thoughts?

2. Crash when deconstructing sf::RenderWindow
When the parent window is closed, I deconstruct the sf::RenderWindow also. Internally, this calls sf::RenderWindow::close(), which prints a warning about how closing a subview is not valid, and then crashes in WindowImplCocoa::~WindowImplCocoa() on line 159: drainThreadPool().

At a total loss due to not having much experience in MacOS/Obj-C coding, I simply commented out drainThreadPool() and the crash stopped. However I suspect this will create a memory leak.

---

I know that SFML is primarily used for games, operating in its own window that it controls, so this might seem like an edge case, but it might be worth considering testing and handling situations like these to make the library more versatile. I really do enjoy SFML.