I have a mobile ThreeJS scene based on device orientation that goes quite good on Android devices (55 fps). After some time performance starts to drop badly, but this is not reflected in the FPS, only in the smoothness of the device orientation detection. And only here, because if I leave the phone on a desk (so device orientation doesn´t play any role) the rest of the code works fine and smooth as expected.
I noticed that closing the browser or even restarting the device doesn´t fix the lack of smoothness. In a moment of dispair, I tried the same script on Firefox mobile, and it was smooth. Going back to Chrome, the problem seemed to be fixed (!).
So every time Chrome gets this lag, I open Firefox to solve it, the weirdest thing. What is happening here? How can I prevent it? Also how can be possible that the fps continue being so high but the device orientation goes so laggy?
If I remember well, this started to happen after using layers on my code (combined with the StereoEffect I was already using). Does this have any sense for anybody? I´m sooo stuck on this.. Any clue will be appreciated.
Related
I have MacBook Pro M1 Max, with two monitors, one 34" as the main monitor and one 24" as the side monitor which I use vertically, after upgrading to macOS Ventura this issue started to appear! When
I tried to watch a video on my main monitor when I switched to full screen, it was showing it sideways!
I'm a software developer so I have multiple browsers, I tried on all of them, and sometimes one was rotating but not the other, but after some time, all were rotating!
I tested Youtube, Amazon Prime, HBO on browsers, and then even the Apple TV app, they all show the videos sideways in fullscreen mode!
But it was happening only on the main monitor, not the side one, not the laptop's internal screen!
Interestingly, the image was showing normal if you moved the mouse pointer on that screen, but as soon as you stopped the mouse, the video go back to the rotated state!
One thing I found out about this was that if you restart the OS, the issue goes away, but after a few times of Sleep/Awake circles, sometimes same day but definitely the next day, it'd come back, and I have to restart the laptop again and again!
SOLVED!
It was frustrating! I called Apple support, and first, they offered to restart the OS and boot in Safe Mode and see if this happens in that mode too, I tried and it was happening in Safe Mode too!
Then the next solution was to reinstall the OS, so I backed up the data as a precaution and reinstalled the macOS Ventura, and it worked the issue has gone away!
So I leave the issue and solution here for future reference.
Here is the link to Apple Support for reinstalling the OS:
https://support.apple.com/en-us/HT204904
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.
Every WebVR app on Android I tried become completely useless after 30 second due to screen timeout in the browser. Is there anyway to prevent it?
There is a (somewhat hacky) solution for this that is being used by the webvr-poyfill.
Android doesn't go to sleep when a video is being played back, so even creating an invisble video-element and playing it will disable the inactive-timeout.
On iOS, a page navigation is initiated and immediately stopped every 30 seconds to keep the screen awake.
Also note that this problem will probably go away when chrome for android ships the real WebVR implementation (probably sometime later this year, when the new daydream-compatible pixel/pixel XL-phones are released)
I think you might find that unless you're on desktop the browser itself is unable to keep the screen on. Instead this can only be sustained by a third party app, or more simply by the user directly through settings.
Simplest solution might be to ask user to adjust settings.
I've built a small game that running perfectly while on local (from Flash). It's a small 60-fps game. Using the same computer, I'm playing the swf using a browser (Chrome, Firefox, Explorer) however it's running extremely slow. I'm using swf monitor (and Browser monitor) there you can see clearly the swf is running with 61/60 fps however this is just not true. Seem like the browser is forcing swf fps down to around the 20 fps or so. I've also tried Wmode (direct / GPU) but nothing. What is going on?
After updating my graphic card drivers, everything works perfectly even on Browser. Flash can handle it perfectly without updated drivers, but on a browser it's a must to have, else it will damage application performance and FPS.
I am in the process of porting a Flash Player-based game over to the Desktop (OSX and Windows) via Adobe AIR (3.1). The porting to AIR itself has gone rather smoothly. The one wrinkle I've been dealt is that the game will be distributed over the Steam network. In order to interact with the Steam Client, I've had to write a native extension to expose the Steam SDK APIs to AS3. The native extension support has been implemented for both platforms, and I have the application launching and communicating with Steam as desired.
The area I've run into trouble is dealing with Steam's Overlay, which renders overtop of games when it is activated. Essentially, when a game is launched, the Steam Client suspends the process in order to hook its Overlay library up to either D3D or OpenGL. Initially, the Overlay failed to appear at all as the AIR application descriptor had the default rendermode set to "auto." However, once I switched the rendermode to "gpu" the Overlay would appear as desired.
On the OSX side of things, everything works as expected. I can toggle in and out of the Overlay just fine. On the windows end of the spectrum, I've hit a bit of a problem when I activate the Overlay. Specifically, when the Overlay is enabled (it's rendering overtop of the game) and I either move the mouse or generate keyboard input, both the Overlay and the game both "freeze" (rendering stops) for 2-3 seconds. Additionally, I have noticed that when I open the Task Manager with the game running, the cpu usage is roughly 75-80%. The cpu usage remains the same when I first active the Overlay (which is desired). However, when I move the mouse cursor or press a key on the keyboard, the cpu usage drops to roughly 1%. This problem has occurred on 4 of 5 windows machines (2 XP, 3 Win 7) we've tested on. Naturally, I first contacted Valve about the issue since this only occurs when the Overlay is enabled. I've uploaded both the OSX and Windows builds for their devs to debug; however, my contact suggested I find out more about AIRs rendering/input as well.
Here is a snippet of a post with a Steam Dev detailing how the overlay works:
"The requirements for the overlay on Windows are as follows:
Game must use D3D7, D3D8, D3D9, D3D10, D3D11, or OpenGL
Game must call D3D Present() or OpenGL SwapBuffers() on a fast regular basis (these calls are hooked by the overlay and give it opportunity to do work). For instance 2D games that only call these functions when mouse movement occurs or graphics on screen actually change rather than every frame will not function well.
Game should use standard Win32 input messages, raw Win32 input messages, or DirectInput for input and the overlay will then detect hotkeys and hide/block input events from the game when active.
It sounds like your game may violate #2 and stops calling Present/SwapBuffers sometimes when the overlay is active. This may happen if you call these functions in response to user input which is now blocked due to the overlay being activated. You should guarantee you keep pumping frames and swapping at a regular interval even if input events aren't occurring."
After a little more prodding, the Valve devs profiled my application to determine if there was any specific problem occuring with the Game Overlay. Unfortunately, they were unable to find anything going on in the Overlay itself. This pretty much means that AIR on Windows doesn't like that the Overlay is blocking Win32 input messages. Here is the Valve dev's response:
"I got your depots and did some testing. Nothing unusual happens in the overlay. Profiling your app with xpref while the issue occurs and taking some minidumps to check callstacks it looks like the app just blocks up completely and uses zero CPU during the time it is blocked, when it happens it calls Present() only at roughly 1 second intervals until it recovers (maybe there is a 1 second timeout somewhere in the AIR code). It's hard to get much detail since I don't have any symbols for the AIR runtime libraries.
It does however look like this is somehow related to input state and AIR being unhappy with win32 input messages stopping. If I change our overlay to not block any input at all once activated (which obviously has some pretty big problems for usability, but just for testing purposes.) then the issue does not occur. It's possible that the AIR code has some weird logic where if it's seen some specific WM_WHATVER message it's expecting another right after and blocks on it waiting somehow.
Hopefully you can work out on your side or with Adobe as to why the application behaves badly in these situations and starts blocking and not presenting at regular intervals."
I've posted on the Adobe forums, but haven't had any such luck over there. Mainly, I'm hoping that someone has either dealt with this before or has an idea about how I could possibly get around the issue. Any suggestions, comments or thoughts would be greatly appreciated!
As it turns out, there is an bug deep in AIR core framework that is the root cause of this issue. Adobe has confirmed the bug, and they are working on a fix for the Cyril (AIR 3.3) release. The status of the bug (#3089755) can be viewed in the Adobe AIR bug list.
In the short-term, I was forced to detect Windows messages that were being consumed by the SteamOverlay, and pass on fake messages to prevent AIR from locking up. I accomplished this by using the Windows API SetWindowsHookEx along with the WH_DEBUG and WH_GETMESSAGE hooks. This is definitely not a desirable approach, but was needed in the short-term until Adobe releases a fix.