Topics

1

Graphics / Possible issue with Apple M1 processor

« on: December 18, 2020, 10:38:17 pm »

I'm not making an issue for this yet because I don't have access to a computer with Apple's new M1 processor, so I can't confirm 100% if the issue lies with SFML or not. But just something to keep an eye out for:

Users of my application on M1 are not seeing any graphics that are being drawn to an sf::RenderTexture. Everything drawn directly to the window seems to be working fine.

2

Graphics / macOS Texture::update -> glTexSubImage2D crash

« on: September 17, 2020, 09:22:09 pm »

Hi,

I'm experiencing a crash in Texture::update. It happens on the line:

glCheck(glTexSubImage2D(GL_TEXTURE_2D, 0, x, y, width, height, GL_RGBA, GL_UNSIGNED_BYTE, pixels));

I am on MacOS 10.15.6 using SFML 2.5.1, self-built with CMake.

The crash is due to EXC_BAD_ACCESS.

Here's where it gets weird.

The image dimensions are 1403 x 132. Since each pixel is 4 bytes, we have a total data size of 740784 bytes. When debugging, the size of Texture::m_pixels is exactly 740784 bytes.

Inside Texture::update(), const Uint8* pixels is a valid pointer to the start of Texture::m_pixels's internal buffer.

However the bad access crash is telling me it was trying to access a memory location 741376 bytes past pixels. It's over-reading by 592 bytes for some reason.

Just to confirm the input arguments once more:
x = 0
y = 0
width = 1403
height = 132

I don't know anything about OpenGL but it doesn't make sense to me that it is reading more data than width * height * 4. Could another application be interfering somehow?

Thanks

3

Window / SFML as a subview

« on: August 13, 2020, 04:56:20 pm »

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.

4

Window / Legacy MacOS OpenGL Freeze

« on: February 04, 2020, 05:15:49 pm »

Hi,

I've been working on an app that I want to be available for older MacOS versions. On MacOS 10.10, this very simple code causes the window to totally freeze up (MacOS shows the spinner icon) when the mouse hovers over it. As soon as the mouse leaves the window, it resumes rendering.

int main() {
    sf::RenderWindow window(sf::VideoMode(800,600), "Test Window");
   
    while (window.isOpen()) {
        sf::Event event;
        while (window.pollEvent(event)) {
            if (event.type == sf::Event::Closed)
                window.close();
        }
       
        window.clear(sf::Color::Black);
       
        sf::CircleShape circ(50);
        circ.setOutlineColor(sf::Color::Red);
        circ.setOutlineThickness(10);
        circ.setFillColor(sf::Color::Blue);
        circ.setPosition(50, 50);
        window.draw(circ);
       
        window.display();
       
       
    }
    return 0;
}

Here is the MacOS spin report:

Date/Time:       2020-02-04 07:48:19 -0800
OS Version:      10.10.5 (Build 14F27)
Architecture:    x86_64
Report Version:  21

Command:         Zivix Graphics Playground
Path:            /Users/USER/Downloads/ZivixGraphicsPlayground-30.app/Contents/MacOS/ZivixGraphicsPlayground
Version:          ()
PID:             908

Event:           timeout-lite
Duration:        10.00s (process was unresponsive for 2 seconds before sampling)
Steps:           101 (100ms sampling interval)

Hardware model:  MacBookPro11,3
Active cpus:     4


Heaviest stack for the main thread of the target process:
  101  start + 1 (libdyld.dylib + 13769) [0x7fff930fc5c9]
  101  main + 685 (ZivixGraphicsPlayground + 19197) [0x100114afd]
  101  sf::Window::display() + 60 (ZivixGraphicsPlayground + 626988) [0x1001a912c]
  101  sf::priv::SFContext::display() + 33 (ZivixGraphicsPlayground + 555041) [0x100197821]
  101  -[NSOpenGLContext flushBuffer] + 27 (AppKit + 3354155) [0x7fff99a52e2b]
  101  CGLFlushDrawable + 66 (OpenGL + 53178) [0x7fff921fefba]
  101  glSwap_Exec + 97 (GLEngine + 119089) [0x7fff98c3d131]
  101  glsFlushDrawBufferIsBackingStore + 307 (GLRendererFloat + 76058) [0x7fff9819e91a]
  101  CGSLockWindowBits + 34 (CoreGraphics + 1337281) [0x7fff8ec237c1]
  101  CGSLockWindowRectBits + 72 (CoreGraphics + 1336943) [0x7fff8ec2366f]
  101  lock_window_backing + 910 (CoreGraphics + 279119) [0x7fff8eb2124f]
  101  CGSWindowSynchronizeBacking + 40 (CoreGraphics + 279926) [0x7fff8eb21576]
  101  _CGSSynchronizeWindowBackingStore + 110 (CoreGraphics + 536520) [0x7fff8eb5ffc8]
  101  mach_msg_trap + 10 (libsystem_kernel.dylib + 70878) [0x7fff8d41d4de]
 *101  ipc_mqueue_receive_continue + 0 (kernel + 1144832) [0xffffff8000317800]

It seems to have something to do with NSOpenGLContext::flushBuffer, though my googling didn't turn up anything very helpful.

Any suggestions are much appreciated!

Thanks,
Jon

5

Window / Legacy MacOS NSOpenGLPixelFormat failure and fix

« on: February 03, 2020, 06:54:32 pm »

Hi,

I'm building an app with SFML and we are targeting older versions of MacOS (back to 10.10). However, using SFML to create the window crashes or hangs in MacOS 10.10.

It seems to be caused by this line:

SFContext.mm

NSOpenGLPixelFormat* pixFmt = [[NSOpenGLPixelFormat alloc] initWithAttributes:&attrs[0]];

pixFmt returns nill which causes the function to return without setting m_context, which is still uninitialized, and then other code tries to use it.

Through more investigation, I found that if I changed this line:

attrs.push_back(NSOpenGLPFAAccelerated);

to

if (@available(macOS 10.14, *))
    attrs.push_back(NSOpenGLPFAAccelerated);

The window opens and draws my objects correctly on 10.10.

I don't know anything about OpenGL, but this test suggests to me that hardware acceleration for antialiasing wasn't supported in earlier versions of MacOS. Can somebody who is more familiar with OpenGL or MacOS comment? And, should this be a patch in future versions of SFML?

6

General discussions / MacOS 10.15 Keyboard Permissions

« on: October 31, 2019, 06:07:13 pm »

Hi,

My Mac computer recently updated to the new MacOS 10.15 Catalina. sf::Keyboard::isKeyPressed() no longer returns anything but false, and this error pops up in the console the first time I do a call to isKeyPressed() for a key:

2019-10-31 11:43:35.409526-0500 <appname>[63159:1973539] [default] 0x100017a54: TCC deny IOHIDDeviceOpen
We got a keyboard without any keys (1)

From a cursory google search, TCC deny IOHIDDeviceOpen is something other developers are seeing when their app tries to get global keyboard access (i.e. seeing key presses even when the app doesn't have focus). It seems that the app has to request keyboard permission if it wants this kind of access.

Is there a built-in window-based keyboard state check in SFML? For example, I'm still receiving keyPressed and keyReleased events, so I could implement my own keyboard class that uses these to update its own state, but this seems like something that should be in SFML already.

Thanks.
Jon

7

General discussions / MacOS SDK 10.15 Crash

« on: October 25, 2019, 04:16:59 pm »

Hi,

I updated XCode to 11.1 yesterday, which replaced the MacOS 10.14 SDK with 10.15. When I got things to compile again, this code caused a crash in renderWindow.create():

int main () {
   
    sf::Window window;
    window.create(sf::VideoMode(800,600), "My Window");
    sf::RenderWindow renderWindow;
    renderWindow.create(window.getSystemHandle());
   
    while (window.isOpen()) {
        sf::Event event;
        while (window.pollEvent(event)) {
            if (event.type == sf::Event::Closed)
                window.close();
        }
    }
   
    return 0;
}

Please note that this is a stripped down example of a much larger and more complex program, made to illustrate the crash. That is to say, there is a reason for the Window/RenderWindow dichotomy, but it's not relevant here.

I found the 10.14 SDK online, downloaded it and switched my project back to 10.14, and now everything runs as it should.

8

Window / OSX Crash in pollEvent()

« on: April 03, 2019, 06:31:53 pm »

Hi,

I am experiencing a crash in pollEvent() on Mac OSX using SFML 2.5.1.

When I create the window using Window::create(VideoMode mode, String title), there are no crashes.

However, for my application I have to give SFML an NSView * that is already created, so I use Window::create(WindowHandle handle).

Traceback is pollEvent()->popEvent()->processEvents()->drainThreadPool->destroyPool()->[pool drain];

Here is the code where the window is opened:

void ZivixGraphicsMacVST::OpenWindow(void * parent) {
    m_cocoaGraphics = (ZIVIXGRAPHICS_COCOA *) [[ZIVIXGRAPHICS_COCOA alloc] initWithZivixGraphics: this];
    setWindow(m_cocoaGraphics);

    if (parent) {
        [(NSView *) parent addSubView: (ZIVIXGRAPHICS_COCOA *) m_cocoaGraphics];
    }
}

setWindow():

void setWindow(void * w) {
    m_Window = new sf::RenderWindow(w, m_sfmlSettings);
    m_Window->setFramerateLimit(100);
}

And the update function up to the point of the crash:

                sf::Vector2i mpos = sf::Mouse::getPosition(*m_Window);
                mouseMove(mpos.x, mpos.y);

                sf::Event event;
                while (getWindow()->pollEvent(event)) { //<<<< CRASH
                        switch (event.type) {

Other code that may be useful in diagnosing the problem:

@interface ZIVIXGRAPHICS_COCOA : NSView {
    NSTimer * m_Timer;
    @public
    ZivixGraphics::ZivixGraphicsMac * m_GFX;
   
}
- (id) init;
- (id) initWithZivixGraphics: (ZivixGraphics::ZivixGraphicsMac *) gfx;
- (void) onTimer: (NSTimer *) pTimer;
@end

@implementation ZIVIXGRAPHICS_COCOA
- (id) init {
    m_GFX = 0;
   
    return self;
}

- (id) initWithZivixGraphics:(ZivixGraphics::ZivixGraphicsMac *)gfx {
    m_GFX = gfx;
    NSRect r;
    r.origin.x = 0.0f;
    r.origin.y = 0.0f;
    r.size.width = (float) gfx->getWidth();
    r.size.height = (float) gfx->getHeight();
    self = [super initWithFrame:r];
   
    // init timer
    double sec = 1/100;
    m_Timer = [NSTimer timerWithTimeInterval:sec target:self selector:@selector(onTimer:) userInfo:nil repeats:YES];
    [[NSRunLoop currentRunLoop] addTimer: m_Timer forMode: (NSString*) kCFRunLoopCommonModes];
   
   
    return self;
}

- (void) onTimer: (NSTimer*) pTimer {
    if (pTimer == m_Timer)
        m_GFX->update();
}
@end

Any suggestions?

Thank you,
Jon