setFullScreen slows down app, produces log

Using Cinder
1

Hello,

When I set my app, Skylite, to be full screen, through setFullScreen(), the app builds and runs, but the performance drops noticeably and the following log appears in the console. I am using cinder 0.8.6 for mac in xcode on El Capitan. I would love to have my app run full screen in the way cinder intended it :slight_smile:

2016-08-25 17:09:27.166 Skylite[51939:2449167] NSWindow warning: adding an unknown subview: <NSView: 0x61000013ad60>
2016-08-25 17:09:27.167 Skylite[51939:2449167] Call stack:
(
0 AppKit 0x00007fff8fbc454d -[NSThemeFrame addSubview:] + 107
1 AppKit 0x00007fff8fbf57ce -[NSView replaceSubview:with:] + 153
2 AppKit 0x00007fff903dd379 __60-[NSView(NSFullScreenMode) enterFullScreenMode:withOptions:]_block_invoke + 159
3 AppKit 0x00007fff8fc6ebdb NSPerformWithScreenUpdatesDisabled + 65
4 AppKit 0x00007fff903dd272 -[NSView(NSFullScreenMode) enterFullScreenMode:withOptions:] + 2972
5 Skylite 0x00000001015d8094 -[CinderView setFullScreen:options:] + 644
6 Skylite 0x00000001015c83ee -[WindowImplBasicCocoa setFullScreen:options:] + 78
7 Skylite 0x00000001015c6f1d -[AppImplCocoaBasic applicationDidFinishLaunching:] + 749
8 CoreFoundation 0x00007fff898e745c CFNOTIFICATIONCENTER_IS_CALLING_OUT_TO_AN_OBSERVER + 12
9 CoreFoundation 0x00007fff897d7634 _CFXNotificationPost + 3140
10 Foundation 0x00007fff85997aa1 -[NSNotificationCenter postNotificationName:object:userInfo:] + 66
11 AppKit 0x00007fff8fc1da8b -[NSApplication _postDidFinishNotification] + 291
12 AppKit 0x00007fff8fc1d7f6 -[NSApplication _sendFinishLaunchingNotification] + 191
13 AppKit 0x00007fff8fc1a946 -[NSApplication(NSAppleEventHandling) _handleAEOpenEvent:] + 574
14 AppKit 0x00007fff8fc1a385 -[NSApplication(NSAppleEventHandling) _handleCoreEvent:withReplyEvent:] + 244
15 Foundation 0x00007fff859ca818 -[NSAppleEventManager dispatchRawAppleEvent:withRawReply:handlerRefCon:] + 290
16 Foundation 0x00007fff859ca689 _NSAppleEventManagerGenericHandler + 102
17 AE 0x00007fff82ce743c _Z20aeDispatchAppleEventPK6AEDescPS_jPh + 531
18 AE 0x00007fff82ce71b9 ZL25dispatchEventAndSendReplyPK6AEDescPS + 31
19 AE 0x00007fff82ce70c3 aeProcessAppleEvent + 295
20 HIToolbox 0x00007fff8eec7c6e AEProcessAppleEvent + 56
21 AppKit 0x00007fff8fc13da2 _DPSNextEvent + 2249
22 AppKit 0x00007fff8fc12e58 -[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:] + 346
23 AppKit 0x00007fff8fc08af3 -[NSApplication run] + 594
24 Skylite 0x00000001015d751d _ZN6cinder3app8AppBasic6launchEPKciPKPc + 461
25 Skylite 0x00000001015b082f main + 191
26 libdyld.dylib 0x00007fff8e49e5c9 start + 1
)

2

Perhaps not a solution, but at there’s at least a few leads here and here

3

Thank you for those leads @lithium

I am experiencing the stuttering as well. It is pronounced. This is what I meant by performance drop.

I am wondering if this is a lag due to redrawing the screen. My target full screen resolution is 1920 x 1080p and I have alternatively had the app height and width set to 1920 x 1080 through setWindowSize before calling setFullScreen in an effort to keep the screen from being redrawn. I still got the stuttering. I am wondering if there is a way to keep the screen from redrawing.

I still get the top desktop window chrome bar when I setWindowSize to 1920 x 1080 and call setBorderless().

4

I don’t notice any slowdown myself so i can’t verify if this will do anything, but have you tried the various fullscreen options? kiosk / exclusive mode etc?

Do you see the same slow down when manually going into fullscreen via the green button? Is your fullscreen resolution considerably larger than your windowed res, and your app just can’t handle the extra pixels?

From memory if you wanted to go the borderless route, you’ll need to manually set the window position to some Display::getBounds().getUpperLeft() to sit on top of the chrome, maybe even -vec2(0, 22).

5

Hi,
does forcing the window to be on top using alwaysOnTop(true) help to hide the windows chrome bar when using setWindowSize and setBordlerless? I have sometimes had to have a delay the call to alwaysOnTop a few seconds after the app launches for it to work.

I often have a key command to toggle this off when setting up installations to make maintenance easier but like the app to aggressively force itself on top.