I want to be able to run my game without a locked framerate (currently 60 fps). The only way that I have found to run the animation is with a NSTimer. Is there a way to have an unrestricted framerate in Cocoa. If so, a link or a code snippet would help greatly.
If you really want to do this, you might need to use the CGL interface. In a valid GL context, CGLGetCurrentContext returns an (opaque) context object. CGLSetParameter can be used to set a value for the kCGLCPSwapInterval parameter. A value of (0) disables waiting for vsync.
This enabled me to get around ~700 frames per second on my MacBook Pro
Download Graphics Tools for Xcode - Late August 2014
Install or just mount Graphic Tools
Open Quartz Debug
Go to Tools -> Show Beam Sync Tools
Select Disable Beam Synchronization
It is not permanent either, perfect for testing/benchmarking.
Source
The Quartz debugger in Xcode 11 (version 4.2) moved this to:
Tools->Quartz Debug Settings->Enable Vertical Sync
Related
I'm experiencing a really weird and frustrating issue with the Android Emulator on macOS Monterey.
I have "tap to click" enabled on my Macbook Pro (Mid 2015 15"), and it works fine in all other apps. But somehow, when the emulator window is active it seems to miss almost every other tap. If I click hard instead of tapping, it catches every click. The tap sensitivity in the Trackpad settings is set to "light".
So, it seems that the emulator window is somehow less sensitive to tapping than all other apps. I don't even know how this is possible, is there even such a thing as app-specific tap-sensitivity??
What's more, it's not only the emulator window itself that has this issue, but the emulator settings window as well. If I tap the "Enable clipboard sharing" toggle, it misses about 50% of the taps. If I click hard, it catches them 100%. If I try the same in some other app (tested with the "System Preferences" window), it catches 100% of the taps.
I have tested and tested this again to make sure I'm not biasing the results, but there really is a difference, and it's driving me nuts. I think it appeared after updating to Monterey, but not 100% sure of the exact timing correlation.
Any ideas??
My problem was really similar, I am using MAC with apple mouse, so I could fix it by disabling the mouse wheel on Android Emulator Extended Controls.
Hope that help
I've noticed the same issue some time ago. Unfortunately, I didn't find any solutions.
However, there are a couple of good enough workarounds:
Launch the emulator in a tool window. Anyway, this is a default approach for modern versions of Android Studio. To enable/disable it check Preferences -> Tools -> Emulator -> Launch in a tool window.
Use alt emulators. For instance, Genymotion doesn't have such an issue.
I ran into a simmiliar issue for me and the solution that i found was enabling "tap on click" to in the "system preferences" -> "trackpad".
I am new to the Android Emulator, but am experiencing the same issue in Ubuntu, even though I have tap-to-click disabled in the OS. I hate tap-to-click, so having an ultra-sensitive-to-touch Android screen emulated on my laptop is beyond frustrating.
Looking at the documentation, I came across the SOURCE_CLASS_POINTER method, which states:
The input source is a pointing device associated with a display. Examples: SOURCE_TOUCHSCREEN, SOURCE_MOUSE. A MotionEvent should be interpreted as absolute coordinates in display units according to the View hierarchy. Pointer down/up indicated when the finger touches the display or when the selection button is pressed/released. Use getMotionRange(int) to query the range of the pointing device. Some devices permit touches outside the display area so the effective range may be somewhat smaller or larger than the actual display size.
In reading that, I've come to believe this may actually be the default behavior due to touchpad events being interpreted through the SOURCE_TOUCHSCREEN method, rather than SOURCE_TOUCHPAD or SOURCE_MOUSE.
Unfortunately, I don't have a solution as much as a workaround:
I plugged in a mouse and tested the pointer up/down movements over the screen, which this part of the document suggests should register as a press. However, with the mouse it only responds to clicks. So it suggests to me that it is indeed properly interpreted as a SOURCE_MOUSE controlled pointer and not a SOURCE_TOUCHSCREEN controlled pointer.
So unless we can find out how to make the AVD properly interpret a touchpad as a touchpad, and not a touchscreen, using a mouse seems like the best solution.
For reference, I'm including this link to the AVD manual: https://developer.android.com/studio/run/emulator
UPDATE: Somehow over the period of about 18 hours and several restarts, my AVD no longer does tap-to-click on its virtual screen. It would be very hard to pinpoint exactly what changed because I've been updating packages frequently since I'm running a pre-alpha release of Ubuntu, but I think it's from using X11 instead of Wayland.
Which got me thinking, you could try changing your display server from Cocoa to X11. Thankfully, MacPorts, the MacOS version of the FreeBSD Ports Tree, makes it fairly easy to cross-compile software. It contains build recipes for multi-platform unix-like software, much like HomeBrew but often allowing for more customization.
That tap issue was annoying enough it's probably worth giving a shot.
(from macports website) The X11 windowing environment, for ports that depend on the functionality it provides to run. You have multiple choices for an X11 server: https://www.macports.org/install.php
I would build them in this order:
MacPorts: X11 - If you build it, you'll have a bunch of libraries already
MacPorts: QEMU - use make configure menu to select GTK3+, if there's no option for X11, try this build flag with make after you install X11 (pointing it at your X11's lib dir):
make -L/opt/X11/lib -lX11
Lastly, MacPorts: Android Platform tools
Related StackOverflow Q/As:
Compiling a C program that uses OpenGl in Mac OS X
Running x11 on Mac OS
I have a problem with OBS. I'd like to make tutorials how to do programming, teach people basics & show them, for example, how to write neural network in Java (without any ML libraries) but in order to do so, it would be great to show them my presentation about it and other windows, so recording full screen is needed (I know I could keep switching windows but it's faster and easier to display full screen). When I added the source "capture screen" the captured screen is black but audio works. I've tried to solve this problem and I went through many tutorials (like 15 or smth) and nothing has helped. I've also added a new thread in OBS Official Forum but nobody has responded. My OBS version is 25.0.4. Here is what I've tried:
- I ran the program as an administrator
- I have reinstalled it (with deleting all files and settings ~ no leftovers)
- In Nvidia Control Panel in 3D Settings I've selected OBS Studio and changed graphic processor to an integrated graphic (also tried dedicated graphic and global choice - nothing worked)
- In GForce Experience I disabled sharing
- Couple times I've restarted the computer and OBS (after any change I've done)
- I ran the OBS in compatibility mode with Windows 8 (and I've tried Windows build-in troubleshooting option)
- I ran OBS with an integrated graphic from a desktop
What I've discovered is the capturing specific window works perfectly, the problem occurs only with capturing full screen.
I have no idea what to do, please help me.
Here is what I see:
It looks like OBS just "can't see" screen, I use only one screen by the way
Black screen
though single-window capturing works perfectly
5
OBS Settings vol.1
OBS Settings vol.2
Logs:
https://obsproject.com/logs/NMexpZp-b4nXDxLl
Specifications of my computer:
I use a laptop - MSI GF 63 8RC
- Intell Core i5 8300H
- GForce GTX 1050 (actualizations are installed) 4GB VRAM
- Windows 10 Home, 64bit (updated to version 1909)
- 16GB RAM
- FHD Screen (1920x1080)
You will need to change the Graphic for this app to integrated graphic
I had the same problem in the virtual machine And I solved it this way go to virtual machine setting
in display section uncheck Accelerate 3D graphics
The problem was solved and the recording was done correctly.
I'm using opengl es 3.0 API with the android studio ndk to create apps.
But I've encountered a very huge problem. I've created a demo app, all it does it change the background color of the screen from white to black and vice versa, every frame. And so when I go to minimize this app, I still see it rendering the background, mostly at the edges of the screen, and not in full color but still very strongly apparent. And it doesn't go away when I close the app, when I restart the device, or when I run "kill apps" on it. Only a factory data reset fixes the issue, so it's not easy for me to debug this.
This is the relevant code that I'm using for when the app is minimized and receives the APP_CMD_TERMINATE event:
eglMakeCurrent(engine->display,EGL_NO_SURFACE,EGL_NO_SURFACE,EGL_NO_CONTEXT);
eglDestroySurface(engine->display,engine->surface);
engine->display = EGL_NO_DISPLAY;
engine->surface = EGL_NO_SURFACE;
I've error checked that eglDestroySurface() is successful.
And I've put debugging messages in to make sure that the main draw loop is NOT executing when the app is minimized. But the problem persists and I don't know what to do about it. Thanks for any help.
UPDATE: well, no one has responded, and I still don't know what to do. Could it be related to threads?
UPDATE: Still can't determine what it is, but for some reason it's messing with the System UI. Willing to upload my entire source code somewhere if someone would be willing to go through this with me, as I'd really like to be able to continue working on my game engine.
Is it the "Strict Mode" developer option on the device settings, perhaps?
That one flashes the screen if an app is blocking.
It would explain why a factory reset changes behaviour.
The answer is not a solution here. The above comment by the user columbo was correct.
I've demoed switching from black to white at high framerates on 3 different android devices, and also my Linux Desktop, all via the openGL api, and it has exhibited this issue on all the devices. So what he said must be correct: this is a problem with LCD monitor technology itself. Interestingly, doing completely random colors does not cause this problem.
I'm trying to run a legacy VB6 application on Windows 10. I'm using creating an .sdb shim file which detects the application's .exe using the Compatibility Administrator tool found in the Windows ADK. Whenever the .exe runs, the screen resolution is resized to a specific resolution. When the .exe stops, the resolution returns to normal.
The Compatibility fixes I'm using are "ForceDisplayMode" with parameters to display at the legacy app's old resolution. And also "ForceTemporaryModeChange" which will revert the screen resolution back to normal.
One problem I'm having is that when the application is open, if I close my laptop lid and reopen it, the .sdb stops working (windows doesn't log out). If I log out, the old resolution is maintained as expected. I'm trying to figure out if there's an option to maintain the .sdb's resolution, or if this is an oversight on Microsoft's end?
Ok, in the off chance that anyone has this incredibly obscure problem in the future, the solution was apparently to disable tablet mode on Windows 10 1809. That solves the .sdb shim being undone by closing the lid on my SP3/SP6s.
Edit: Ok, turns out that was not the solution. It was just coincidence, so I've uncheckmarked this answer. We had an image that didn't have this problem but then later images reverted this behavior. Still don't know why this occurs.
Edit 2: I still don't know why this occurs but I have a few observations that may help someone. I'm on Windows 10 LTSC Version 1809 Build 17763.615. It seems to have to do with specifically putting the SP6 to sleep via flipping up the keyboard. If you sleep by Windows > Power > Sleep or pressing the power button or letting the SP6 go to sleep on its own, the SDB is correctly maintained. Another odd observation is that if you sleep via the 3 ways listed above but then flip up the keyboard, the SDB is cancelled.
I prefer google chrome in almost every way above IE10, but one thing I hate is that fonts just look much better in IE10. This especially visible with small math fonts. They look like pdf quality in IE10.
After searching a little bit, I found out that this is because IE10 use DirectWrite in windows 7/8 for font rendering. I was searching if chrome will support this in the future and I found this information:
Apr 24, 2013:
An update for everyone that's watching this one:
Our Windows font rendering is actively being worked on. Basic support
for DirectWrite is now in Skia (to update from comment #13). At the
same time, GDI was very deeply embedded in the Windows WebKit port and
is still being rooted out. We hope to have something within a
milestone or two that developers can start playing with. How fast it
goes to stable is, as always, all about how fast we can root out and
burn down any regressions.
We'll update the thread here when it's available behind a runtime flag
for y'all to try out.
Oct 8, 2013
The following revision refers to this bug:
http://src.chromium.org/viewvc/blink?view=rev&rev=159071
Changed paths: M http://src.chromium.org/viewvc/blink/trunk/Source/core/platform/graphics/skia/FontCacheSkiaWin.cpp?r1=159071&r2=159070&pathrev=159071
M
http://src.chromium.org/viewvc/blink/trunk/Source/core/page/RuntimeEnabledFeatures.in?r1=159071&r2=159070&pathrev=159071
Add runtime flag for using DirectWrite on windows
Add runtime enabled feature for using the DirectWrite skia backend on
windows.
BUG=25541 R=bungeman#chromium.org, eseidel#chromium.org
Review URL: https://codereview.chromium.org/26335002
I don't even know what a runtime flag is, but this sounds to me that it may be possible to somehow enable directwrite in chrome. Is this true ? Or should I wait a little longer before I can use directwrite font rendering in chrome ?
Sadly not yet (as of 2013-10-31, no Chromium channels supports this feature out-of-the-box).
If you look at the latest RuntimeEnabledFeatures.in, DirectWrite doesn't have any status assigned to it. According to Blink document, users cannot enable a feature via about:flags unless status=experimental is assigned.
But hopefully soon, so windows users may have a better time with web fonts :)
Update 2013-11-16: with latest issue 25541 comment, it seems we are very close to be able to enable DirectWrite in Canary.
Update 2014-01-04: Canary build now has a command line switch that can enable DirectWrite font rendering, but disabling sandbox mode are required (not safe for everyday browsing). There are also a few font rendering problem associate with it. Hopefully they can get them fixed and add this feature to about:flags soon.
Update 2014-05-09: latest Canary build (m36) now has proper support for DirectWrite within sandbox mode (implemented via issue 333029), which means developers can enable DW directly by going to about:flags#enable-direct-write. As for consumers, Google is targeting release on m37.
Update 2014-08-09: Chrome 37 beta enables DirectWrite by default, expect Chrome 37 official release to have it by default as well.
Update 2014-08-31: Chrome 37 stable release has DirectWrite enabled by default! Just note that users can still turn it off at about:flags (some of them use MacType instead).
Chrome 35 (beta) comes with an option to enable DirectWrite for Windows font rendering. Paste the following command in your address bar and click enable:
chrome://flags/#enable-direct-write
Reference: http://www.reddit.com/r/web_design/comments/22q9r9/chrome_35_beta_has_finally_fixed_windows_font/
It's currently in development for chrome on windows.
http://www.chromestatus.com/features/4725550652325888
Update: on August 26, 2014, Google updated the stable version of their Chrome browser to version 37.0.2062.94 on Windows, OS X, and Linux. With this release, Chrome move from Microsoft's Graphics Device Interface rendering method to Microsoft's DirectWrite text rendering API. Switching to DirectWrite has been requested for years by users on Windows, and Google has stated that it took significant rewriting of their font rendering engine which is why it has taken so long.
It's in Chrome as a flag as of 33 (and as of this time of writing), however from what I understand you still need to run it with the sandbox disabled via the command line --no-sandbox. This is not a recommended action for everyday use. You can enable the rendering flag, but it will only change if sandboxing is disabled.
(I would have added this as a comment to #chickenbooze, but I've switched SE accounts and don't have enough reputation yet :)