Sorry for the without of code, but has anyone encountered the problem of automatically shifting the X position when using Autoresizing layout. It looks like when I set the position X: 0 it will save the project, exit xcode will run it again I have X: -1, will I run again: X: -2 then X: -3 etc etc etc what could be the reason?
Xcode ver. 14.2
Related
I am using xlib to set window to certain position using XMoveResizeWindow function
All works fine, but when I want to 'stick' my window to left part of screen, I get the wrong position and size: there is a space between window and left, top and bottom screen borders.
To find out 'right' coords & dimensions of window stuck to left manually, I have written a watcher program which continuously calls XGetGeometry and prints results to screen, so I got these results of a 'stuck' window:
X: -40
Y: 14
W: 2000
H: 2426
When I pass these values to XMoveResizeWindow function, I still get the wrong position.
I have extended my watcher program to print all available properties of the window to see which will be changed when I manually 'stick' the window, but nothing changed except max_width and max_height fields of WM_NORMAL_HINTS property.
If you have an idea what am I doing wrong, please let me know.
I'm testing the title editor that comes with Xcode 8 (8.2.1). It seems that there's a major bug. I can create a tile map. But if I set the title size to 32 x 32 and then quit Xcode and reopen the same project, Xcode resets the size to 128 x 128. According to this post, it's a known bug. Does anybody know a fix? If Xcode redefines the tile size every time I open a tile map, it's kind of useless. Thanks.
I am very new to apple computing, have my first iMac a few months. I am now learning basic code writing. I had found a useful link on you site that turns on view history and displays a graph
of the output, just some dots on the screen. In that post it said to
go to editor tab and select result display mode to enable value history,
all options are grayed out.
Here is my code and version information.
Note I am using Playground, set up as OS X
import Cocoa
for x in ["1","2","3","4"] {
print(x)
}
System Imac
OS = OS X Version 10.11.5
Xcode Version 7.3.1 (7D1014)
Swift 2.2
Thanks All
Harry Nash
First, notice that you are using array of strings. Therefore, you cannot create a graph.
For the rest of your question, on the right side of the screen you can find the eye button and a circle next to it. Click on the circle. This will open a box under the print(x) statement. Right click on the box and select Value History from the menu.
Below an example of almost same code, but with integers
import Cocoa
for x in [1, 2, 3, 4] {
x
}
I'm making a fairly complex sprite kit game. I recently added support for OS X. I get 60 fps always, regardless of how my game is scaled when the window is resized (even when resized to max screen space). However, the moment I make my App enter "Full Screen," the fps drops to 30-40 fps and stays that way? But if I take my mouse cursor and reveal the menu bar while full screen is enabled, the fps goes back up to 60 fps!
You can even test this bug by making a sprite kit game for mac in Xcode using the default template. Here are the screen shots I took of the default game template for mac.
I suggest trying it out for yourself, you don't even have to write any code if you use Apple's default sprite kit template for OS X.
Max Window (No FPS Problems: 59-60 FPS)
Full Screen Mode (FPS Drops to 30-40 FPS)
Full Screen Mode With Mouse At Top Revealing Menu Bar (Surprisingly, NO FPS Issues: 59-60 FPS)
Anyone have any idea what might be causing this problem. I don't want to release my App with full screen mode if it means users will lose performance. You would think full screen mode could better optimize drawing but apparently it's quite the opposite. I'm running this on Yosemite.
Ok, after weeks looking into this issue I have found some workarounds to this issue. Before I begin, let me start by explaining my setup. I'm using an NSViewController in a storyboard which holds an SKView. I've tested the workaround on MacBook Pro (Retina, 15-inch, Early 2013), I have no idea if the workarounds I present below will work on other Macs. I believe it should, when I get the chance I will test and see if the workarounds below work.
So before I begin, lets recap what the issue is. The issue is that making your App enter fullscreen by clicking the fullscreen button causes a massive drop in FPS. Below is how you enable the fullscreen button:
self.view.window!.collectionBehavior = .FullScreenPrimary
So then I searched around and found a different way of entering fullscreen using this code:
self.view.enterFullScreenMode(NSScreen.mainScreen()!, withOptions: nil)
But I still had a massive drop in FPS. Keep in mind, I had no fps issues when in maximized window mode or even full screen with the menu bar visible! (see pictures in question).
So then I tried a less high-level approach to going full screen. I found a guide by Apple here
Using some of the code from the guide, I managed to enter fullscreen by setting the window size to the size of the display, and positioning the window above all OS X UI. The code for this is as follows:
self.view.window!.styleMask = NSBorderlessWindowMask
self.view.window!.level = Int(CGWindowLevelForKey(Int32(kCGMainMenuWindowLevelKey))) + 1
self.view.window!.opaque = true
self.view.window!.hidesOnDeactivate = true
let size = NSScreen.mainScreen()!.frame.size
self.view.window!.setFrame(CGRect(x: 0, y: 0, width: size.width, height: size.height), display:true)
But, sadly, same problem... The FPS just dropped just like before.
So then I thought what if I mess with the size/position of the window. So I tried moving the window down so that just the menu bar was visible as shown below. AND THIS WORKED. I no longer had a drop in fps. But obviously it's not truly fullscreen because the menu bar is visible
self.view.window!.setFrame(CGRect(x: 0, y: 0, width: size.width, height: size.height-NSApplication.sharedApplication().mainMenu!.menuBarHeight), display:true)
In fact, as it turns out, just be adjusting the window size by 1 point fixes the drop in fps. Thus the bug must be related to an optimization (how ironic) apple does when your window size matches the screen size.
Don't believe me? Here is a quote from the link.
OS X v10.6 and later automatically optimize the performance of
screen-sized windows
So to fix the issue all we need to do is make our window size height 1 point larger which will prevent OS X from trying to optimize our window. This will cause your App to get slightly cut off on the top but 1 pixel shouldn't be noticeable at all. And in the worst case you could adjust your nodes position by 1 point to account for this.
For your convenience, listed below are the 2 workarounds. Both of these workarounds do not cause any drop in FPS. Your App should function just like it did in maximized window mode. The first workaround puts your App in fullscreen and displays the menu bar at the top. The second workaround puts your App in complete full screen with no menu bar.
Workaround 1: Fullscreen with Menu Bar
self.view.window!.styleMask = NSBorderlessWindowMask
self.view.window!.level = Int(CGWindowLevelForKey(Int32(kCGMainMenuWindowLevelKey))) + 1
self.view.window!.opaque = true
self.view.window!.hidesOnDeactivate = true
let size = NSScreen.mainScreen()!.frame.size
self.view.window!.setFrame(CGRect(x: 0, y: 0, width: size.width, height: size.height-NSApplication.sharedApplication().mainMenu!.menuBarHeight), display:true)
Workaround 2: Fullscreen with no Menu Bar
self.view.window!.styleMask = NSBorderlessWindowMask
self.view.window!.level = Int(CGWindowLevelForKey(Int32(kCGMainMenuWindowLevelKey))) + 1
self.view.window!.opaque = true
self.view.window!.hidesOnDeactivate = true
let size = NSScreen.mainScreen()!.frame.size
NSMenu.setMenuBarVisible(false)
self.view.window!.setFrame(CGRect(x: 0, y: 0, width: size.width, height: size.height+1), display:true)
If for some reason these workarounds don't work, try messing some more with the size/position of the window. Also you may need to change the window level depending on if you have other views such as dialogues that your App should not overlap. Also please remember to file bug reports with Apple.
Additional Info About NSBorderlessWindowMask
These workarounds use an NSBorderlessWindowMask. These type of windows do not accept keyboard input when the key window changes. So if your game uses keyboard input, you should override the following. See here
class CustomWindow: NSWindow {
override var canBecomeKeyWindow: Bool {
get {
return true
}
}
override var canBecomeMainWindow: Bool {
get {
return true
}
}
}
Update: Some bad news
Tested this workaround on Mac Book Air, and it did not work unless about 100 points were subtracted (which obviously is extremely noticeable). I have no idea why. Same goes for andyvn22's solution. I also have noticed that very rarely, perhaps once every 60 launches the workarounds provided simply don't work on the Mac Book Air at all. And the only way to fix is to relaunch the App. Maybe the Max Book Air is a special case. Maybe lack of a graphics card has to do with the issue. Hopefully Apple gets the issue sorted out. I'm now torn between supporting fullscreen and not supporting fullscreen. I really want users to be able to enter fullscreen mode, but at the same time I don't want to risk users loosing half their FPS.
Based on Epic Byte's very helpful work, I found an even easier way to disable Apple's full screen "optimization". You can still use OS X's built in full screen capability; all you have to do is implement the following method in your window's delegate:
func window(window: NSWindow, willUseFullScreenContentSize proposedSize: NSSize) -> NSSize {
return NSSize(width: proposedSize.width, height: proposedSize.height - 1)
}
Unfortunately adding one pixel doesn't seem to work this way, only subtracting one, so you lose a row of screen space. Totally worth it to me, though, to continue using the built-in full screen function, especially while just waiting for Apple to fix their optimization bug.
I believe this problem occurs on all apps using OpenGL to render. MPV (video player) with the following video config has the same issues: vo=opengl hwdec=no
Cpu usage - windowed: average 42%
Cpu usage - fullscreen (native): 62%
Cpu usage - fullscreen (non-native/in app): 60%
Cpu usage - fullscreen (native with menu bar): 45%
Cpu usage - offscreen (using native full screen): 95%
This also occurs on PPSSPP with OpenGL backend except with increased GPU instead of cpu usage:
Gpu usage - windowed: average 20%
Gpu usage - fullscreen (with menu bar): 20%
Gpu usage - fullscreen (native): 35%
Gpu usage - offscreen (using native full screen): 90%
This problem however does not seem to occur when developers implement their own "Special" fullscreen. In the case of Enter the Gungeon, where cpu usage and gpu usage shows no difference between windowed and FS. Although I haven't had time to check how they've implemented fullscreen yet.
Tested on MBP Late 2015 13' on OSX 10.11.6
The slightly increased usage during fullscreen is a bit annoying as you've said and can cause framedrops, but what's worrying me the most is the near 100% usage of both CPU and GPU in openGL applications when in background. (Note: it's 90% on ppsspp no matter what it's doing, even when paused).
I have a multi-monitor Mac desktop (4 displays each of 1920x1080 arranged in a 4x4 rectangle) and can use a mouse to open a window across all monitors, filling the whole four screen desktop.
(am running Mavericks and have disabled the "Displays have separate Spaces" checkbox)
I want to be able to so this automatically, so used AppleScript. However, the window will not open to a height greater than one of the displays (1080 pixels), even though the displays are arranged in a 4x4 matrix so that the total height of the desktop is reported as 2160 pixels. Window width is no problem and the script opens nicely across displays horizontally.
Here is the key part of the AppleScript:
tell application "Finder"
set bounds of first window to {0, 0, 3840, 1800}
end tell
There seems to be some kind of limit on the vertical size of the window. Any ideas how I can achieve automation?
Googling has pulled endless gripes about multi-monitor support on Mavericks but I can't find anything related to this particular issue.
Thanks in advance
BACKGROUND
I've tried this on two multi-monitor display configurations:
Early 2014 Mac Pro.
Four external 1920x1080 monitors arranged landscape in a 2x2 rectangle.
Reported desktop size is {0, 0, 3840, 2160}
MacBook Pro Retina Late 2013:
Two external 1920x1200 monitors arranged one above the other
(and the laptop's own 2880x1800 internal display of course)
Reported desktop size is {0, 0, 3360, 2400}
I don't have multiple monitors to test this, but on my one monitor the (0, 0) point is the upper left corner of my screen. Maybe you need to adjust the second number of your bounds. My suggestion would be to open a window manually by hand. Then run this code to get the bounds. Then try to set the bounds with the returned values. Of course I still don't know if this will work but at least you'll know you're working with the proper bounds. Good luck.
tell application "Finder"
return bounds of window 1
end tell
EDIT: once you know the proper bounds, you might try using System Events to resize the window. System Events doesn't know "bounds", but it does know "position" (the first 2 numbers in your bounds) and "size" (the second 2 numbers in your bounds). Try this with your numbers.
tell application "System Events"
tell process "Finder"
set position of window 1 to {0, 400}
set size of window 1 to {800, 500}
end tell
end tell
Not to revive a dead subject, but with some external dependencies it is possible to resize larger than the monitor resolution. You need a program called MegaZoomer [https://github.com/ianh/megazoomer] ... and you need EasySIMBL [https://github.com/norio-nomura/EasySIMBL].
Install EasySIMBL first, (can be downloaded from http://www.macupdate.com/app/mac/44354/easysimbl ). Then pull down MegaZoomer from (http://www.macupdate.com/app/mac/21275/megazoomer) ... copy the megazoomer package into the EasySIMBL packages dir. You will need to enable the package in SIMBL. You may have to reboot. Then run your applescript and it should work.