I recently installed Android Studio to learn more about app development. However, I'm seeing screen tearing to such an extent that the IDE is pretty much unusable. Demonstration in the photos below:
Example showing a typical screen tear
Example showing NO tearing (same project, same editor view - captured by minimising the window, re-maximising it, then quickly taking the pic)
For the avoidance of doubt, this screen tearing is only happening within Android Studio on my Windows 10 machine. No screen tearing happens within games, editors such as Notepad++, or suchlike.
Some of the things I've tried to pinpoint the issue:
Changing my graphics card settings, back when I didn't know it was limited to Android Studio. I have a GeForce GTX 980, and various googling led me to tweaking VSync to adaptive and Triple Buffering to On in the hope it resolved the issue. I also tried changing my two identical monitors' refresh rate (connected via Display Port cables, Extended desktops) from 60hz to 59 and 50 to see if it might resolve it. No luck.
Changing many of the Android Studio appearance settings e.g. turning window animations on or off, changing the tooltip MS delay timer, turning off file synchronization/file saving on frame activation and background saving entirely, etc.
Even changing the Android Studio config e.g. -Xmx2048m instead of the default 750mb.
In terms of triggers, the issue is intermittent, but when it does start, it's there until I reboot my machine. In other words, it doesn't relate to my running a phone emulation or having a specific phone emulated, nor what other programs are running on my machine at the same time, nor if the phone "preview" screen is showing, nor if a gradle build is running in the background, etc.
Other interesting aspects that I've spotted are:
The screen tearing seems to be concentrated around where the mouse cursor or keyboard input is located, not randomly on the screen.
I think the issue is not occurring when my monitors are set to Duplicate their displays, rather than Extend. I'm not 100% sure on this yet though; I certainly haven't seen it in half hour experiment using the Duplicated monitors.
I'm now out of ideas, and ready to give up on Android Studio.
Although this feels more likely to be a hardware or graphics issue, because Android Studio is the first and only thing that I've experienced issues with, I was hoping someone else may have an answer about what else to try.
I was having this issue as well on Android Studio 2.0. I fixed by disabling G-Sync on my Nvidia GTX980
See Android Issue Tracker http://code.google.com/p/android/issues/detail?id=189308 ("Screen garbled / messed up when repaint on 1.4").
Related
While researching this I was writing an answer to IntelliJ IDEA: Breakpoint not being hit, and is shown without the tick, just a red dot until I realised it is a completely different question. I have had this issue twice in the past 4 weeks, but my use-case is IntelliJ is no longer ticking the red breakpoints. I just watched the ticks fall away before my eyes.
First time it occurred was after unceremoniously ripping out the USB cable in a hurry. I don't appreciate the need for ceremony here. That broken project remains so.
I tried everything to fix it, and gave up on that particular project; it was largely complete. I tried adb kill-server and the general family of off-then-on-again solutions to no avail.
Fast forward a couple of weeks I'd forgotten about it and was delighted (I tell a lie, I was taking it for granted) to be able to test my new protocol with breakpoints on an Android device. First symptom was my icons messing up (I thought I must have had a trapped thread somewhere in the IDE but find it hard to believe I wouldn't have noticed that with just the single process being debugged). Next the breakpoint's tick just dissappeared and I had a blue message in the IDE's console, something about GDX and taking too long with the graphics (similar message appended at bottom of post). Foolishly I restarted the apk.
What haven't I tried? I'm thinking something drastic like persevering with Desktop only development, or ditching Windows. I thought about upgrading (contracting) Gradle but my other project was brand spanking new and recently diagnosed with specific Gradle version dependencies.
I can start the app from my dev machine but even pausing isn't able to find what it is doing because it will pick a (random) thread out of context with my app.
I can also hit breakpoints from the Desktop app
I suppose I should try Android Studio with this project but know that won't be an easy fix. I'm using Win10 Pro and on brand laptop and phone (nothing fancy mind). I'm using Gradle 2.1 (IIRC, I get a daily nag to upgrade to 4.1) but my other similarly fated project has specific dependencies on Gradle versions so I want to leave well enough alone.
I don't know if it's the answer or not, but it seems to work fine with the emulator, which would seem a more universal solution than something as challenging as, you know, supporting a bunch of different hardware. I ran it again and trapped a certain line, observed the same screen artifacts as before, but killed it before I could lose my emulator too.
This is the last thing she printed:
W/zygote: Long monitor contention with owner GLThread 260 (8155) at boolean com.mygame.game.screens.Menu$4.keyDown(int)(Menu.java:128) waiters=0 in boolean com.badlogic.gdx.backends.android.AndroidInput.onKey(android.view.View, int, android.view.KeyEvent) for 9.799s
It was trapped in a different method but the gist of it is I've blocked the GLThread.
my first android game it's almost done, and I'm on the way to publish it on the play store.
Today I tested it on some friends phone and it worked on all except for a samung a5. On this phone the meshes flicker, apper and disapper and look deformed. This when playing game where I use a lot of frame buffer, in the main menu where there is a simpler animation everything look right.
The game is developed with libGdx and use some custom shader. I've tested it on 8 other different device without no issue (excepect for low frame rate on samsung galaxy tab s4).
I ask yours advise:
1) what should I start to check to find the problem with a5?
2) do you think I should delay the publication until the bug it's solved ora I should publish it excluding A5 ( or maybe all devices with similar GPU) from compatibility list?
My big problem is that at the moment I don't have the device with me (it's the personal phone of a friend of mine...) and probably I will have it for only a limited amount of time, so I want to be preparated to avoid to lock the device for too much time to my friend.
Thanks to all!
First, I'd make sure you don't have any OpenGL errors - add calls to glGetError and validate frame buffers and shader programs, you can do this without the device and adding extra asserts like this is always worthwhile (assuming you don't already have them). Next, try using the tools provided by the GPU manufacturer. In your case the snapdragon profiler. To minimize the time you'll be using your friends device, get the tools installed ahead of time and if you have access to another Qualcomm device, then use that to familiarize yourself with the software. With luck the cause of problem might become immediately obvious. If not, then it's just a binary search of disabling parts of your code until you narrow it down to a particular shader/draw call, then examine/tweak that to figure out what bit is going wrong.
That's a tough call. If it's a driver bug, then it might only occur on particular revisions. Some A5 devices might work if they're on different versions of Android from your friends device. That said, the A5 is relatively recent and Samsung/Qualcomm drivers tend to be pretty solid IME, so it's more likely an error in your code that happens to only be exposed on certain devices. Personally I would delay release unless your release strategy is timing sensitive, from the limited data you have, your game doesn't work on >10% of devices.
I recently had to reinstall Android Studio as a last ditch attempt to fix the "java_find.exe not found" bug. Unfortunately, this new build seems to have a radically different AVD interface that makes me unable to configure a lot of aspects of my virtual devices that I would have been able to with the original format and worse seems to only create emulated devices that never progress past the boot-up screen. After an extensive amount of google-ing I seem to be the only one on the planet who has this interface, so any explanation or advice would be massively appreciated.
(EDIT) Here's an image of an emulated device I just made. For the API I have no other option other than different versions of 21. In this case I chose the first option.
However, the same problem still persists where the emulator never progresses past the android screen. (It's been running for 10 minutes now when before my emulators would start in less than two.)
I've also just noticed this error hidden way in the bottom left corner of android studio.
"Could not find a matching system image for ABI x86, API 19/null: Could not find a matching system image for ABI x86, API 19/null"
Could this be related at all?
After an extensive amount of google-ing I seem to be the only one on the planet who has this interface
Fear not! I have the same screen. I installed android studio last week and I'm on the Beta version 0.8.14
Unfortunately, this new build seems to have a radically different AVD interface that makes me unable to configure a lot of aspects of my virtual devices that I would have been able to with the original format and worse seems to only create emulated devices that never progress past the boot-up screen.
I just created an AVD for the sole purpose of trying to recreate the issue. I created an AVD with a Nexus 4 and api 19 (kitkat 4.4.2), then booted it by pressing the play button in the Actions area.
It did take a couple mins (~4) but eventually it booted and now works fine.
any explanation or advice would be massively appreciated.
Explanation: sadly don't have one
Advice: reinstall and see what happens. Or show me your actual virtual devices screen so I can try and reproduce your errors.
Edit
I created a new AVD with the same specs as yours, and it booted fine.
Do you have these system images installed? (in SDK manager) or at least the one(s) you are trying to use for your AVD
Ever since updating to the latest ADT (version 18), I've noticed that there seems to be some sort of odd lag between what's happening on device emulators and what various tools are seeing. For instance, if I set a breakpoint in Eclipse and then attach the debugger to a running app, the debugger will miss the first time that the breakpoint is reached, breaking only on subsequent executions. Similarly, if I try to take a screen snapshot with the Devices view, the image is always from one or two screen changes back. Similar behavior happens if I run hierarchyviewer outside of Eclipse, so I don't think it's an Eclipse problem specifically.
I should mention that the part of the app that I've tested this with has static screens that change only on user input (that is, no animations or background threads); so it's not just a communication lag. I can change screens, wait five minutes, take a screen snapshot, and still get an image of what had previously been on the screen. Screen snapshots in perticular never seem to catch up. (Repeating the snapshot still generates the previous screen, not the one on display.)
Has anyone else seen this behavior? Does anyone know how to fix it?
UPDATE: This is on a Windows 7 machine running Java 1.6.0_26 and Eclipse 3.7 (Indigo).
The Google/Android team have been enhancing the emulator images with the ADT updates like GPU support and sensor injection. If you are using old emulator builds (AVDs) from when you first created your work environment (say months ago) you will want to recreate them fresh from the new tools and see if the problem resolves.
Well? I've tried increasing the RAM size of the emulator to 1024 MB and there was little improvement on the speed, however, it's still unusable. It has the speed of a turtle.
Anyone got better ideas to make it faster? Is there something I'm not doing correctly?
Check out the android developer documentation regarding 3.0 emulator performance. Scroll down to About Emulator Performance.
Copied tip for convenience:
Tip: To improve the startup time for the emulator, enable snapshots for the AVD when you create it with the SDK and AVD Manager (there's a checkbox in the AVD creator to Enable snapshots). Then, start the AVD from the AVD manager and check Launch from snapshot and Save to snapshot. This way, when you close the emulator, a snapshot of the AVD state is saved and used to quickly relaunch the AVD next time. However, when you choose to save a snapshot, the emulator will be slow to close, so you might want to disable Save to snapshot after you've acquired an initial snapshot (after you close the AVD for the first time).
Seems like everything 3.0 and beyond is slow for me. Everything before that runs very fast in emulator for me. However, I have an Intel integrated graphics card in my laptop. When I turn 3D setting to "Application Settings," I get relatively decent performance from the emulator, at least when it starts up, but then when I try to start any app from the default main app menu (contacts, for example) I get launcher errors. That happens for me on 3.0, 3.1 and 3.2. The one thing I'm suspicious of is that I'm running 64-bit Java SDK. Seem to be a number of posts out there related to 64-bit, but mostly they seem to be point to using 64-bit SDK with 32-bit Eclipse or vice versa, but in my tests, I am not even running Eclipse, haven't even reinstalled the ADT yet, just the Android SDK and created a few emulator instances. Again, prior to 3.0 everything is fast. 3.0 and beyond not good, but A LOT better with graphics settings as I mentioned above. If I could get past the launcher issues, I think I might be all set. Oh, btw also, for 3.0 and beyond, I bumped the memory up to 1024. I've tried increasing the heap for apps to double the default (from 48 to 96) but that doesn't seem to have alleviated my launcher problems.
It is slow. You can try creating a new Emulator with a smaller resolution.
I remember someone at google I/O saying that the HoneyComb emulator will run really really slow due to hardware acceleration turned on.
The PC may use software rendering for OpenGL hence the bad performance. The almost everything you see on the HoneyComb screen is rendered using OpenGL ES.
감사합니다,
Reno