Since a while ago I started having some artifacts on some android devices. I have checked build settings, I was disabling code stripping and setting all options to the default ones - nothing worked out.
This visual interference (see screenshot) happens at least in Note II and HTC One Mini/2. Nexus 5 exhibited very minor interferences.
Any help would be highly appreciated!
Picture here
Well, that was quite obvious, I just needed to turn on my brain, lol.
So, if you're having issues with rendering like I was - try to check your main camera.
And especially be careful with Clear Flags property. Personally, I have faced with a situation when some of my background layers (which have SpriteRenderers on) were switching their alpha values. At that point camera would "see" through the layers. And that is the problem if you have "Don't Clear" value in "Clear Flags" property.
Hope it helps.
which Unity version are you using? Can you make sure to use ETC1 compression (+alpha if needed) and try again on those devices?
Related
CSS' mix-blend-mode seems to fail on Android 9:
Chrome
Webview in Cordova (also Chrome in that case, probably)
It works on:
Chrome on Android 8
Firefox on Android 9
I initially experienced the issue with an SVG element, but I am also able to reproduce it with some simple divs.
A very simple code example:
https://codepen.io/walmink/pen/YoJRqa
I tried to run the example below and get the expected result on a Nexus 5 running Android 8 (left), but it fails on a OnePlus 6 phone running Android 9 (right) (see image). I've had other users (of a game of mine that uses mix-blend-mode) report the same issue on a OnePlus 7 and a Google Pixel 3a XL running Android 9.
It also seems to work fine on any desktop browser I've tried. On Safari, it will blend with the background as well unless you add isolation: isolate, but at least the blending still happens.
Thank you for tracking down that Chrome issue! I've been debugging this all day but missed that one. I'm on a OnePlus 6t. Someone else wasn't able to reproduce on a Pixel 2, but glad to hear it is in fact happening on other devices.
I have a workaround, which I'll also address in that Chromium thread, soon.
Option 1: Force hardware acceleration on the blended element, using something like transform: translate3d(0,0,0);
Option 2: On the blended element, add a will-change property, set to pretty much anything. will-change: opacity; for example, would suffice. This forced re-paint seems to be enough to kick the blend-mode back into gear.
Now, this fixes the problem... but causes another. If you have to do any scrolling more than about one more page length, the blended element will eventually get cut off, and will remain invisible for the rest of the page.
This behavior (or similar) is described here:
https://bugs.chromium.org/p/chromium/issues/detail?id=798148
This one sounds almost identical, but but is marked as fixed.
https://bugs.chromium.org/p/chromium/issues/detail?id=992398 This one also sounds similar, but they've identified as being related to the max size of a layer, which is fairly large (some 8000px). Whereas the behavior you'll find with this workaround, is more like 2000px, or roughly 200% of the height of the viewport (hard to test).
Unfortunately this cut off content behavior is very consistent... That Pixel 2 user I mentioned before, that couldn't reproduce the initial blend-mode issue, was seeing this cut off once the workarounds were applied.
You said you're making a game though, so hopefully there's not much scrolling involved?
Also, for what it's worth, you may find the screen blend mode is exempt from all this and may still work without any workarounds.
You can test with this https://codepen.io/chasebank/pen/wvwWGxd The workarounds are commented out in the .box element.
Good luck!
We use the Android Premium SDK of HERE in our application containging truck navigation. We have just upgraded from version 3.3 to 3.8, and and we experience a quite strange problem. The app started to use the CPU and the GPU very much after this upgrade. We made some investigations and the followings are happening:
The extra CPU and GPU usage occurs when truck restrictions are displayed on the map, that is when we use: map.setFleetFeaturesVisible(EnumSet.of(Map.FleetFeature.TRUCK_RESTRICTIONS));
We tested such that we set all the layers invisibile with map.setVisibleLayers(), and the truck restrictions were displayed. However, the app is still very slow. Nothing changed.
Using the map.setFadingAnimations(false); helped a little bit, but not too much.
We are trying to solve the problem with different tilt angles by using map.setTilt(). It looks like this helps, but it is still worse than with the version 3.3.
Based on these facts, we believe the problem is with the amount of markers displayed when TRUCK_RESTRICTIONS are required. It is noted here: https://developer.here.com/documentation/android-starter/dev_guide/topics/development-tips.html , that too many objects can cause performance problems. However, we cannot modify the amount of objects with TRUCK_RESTRICTION, and in cities (e.g in Budapest) there are many restrictions.
Does anyone have any advices on what should we do?
Thank you in advance!
Thank you for bringing this to our attention. We are working on a solution and plan to fix this within the next SDK release (3.10).
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").
I downloaded the samples from OpenCV for Android and let them run in eclipse on a real device (Nexus 7). They all work fine, but when I'm looking at the LogCat log, I see ca 20 errors displayed for each frame. The log is filled with them. Although all the samples work, this irritates me and makes it hard to debug the code.
Here a screenshot of the log:
Does anyone know where these errors come from and what they mean?
Should I worry about them, if no: can I somehow hide them? if yes: what to do?
Another question:
I get, when running the JavaCameraView idle (Sample CameraPreview) only 15fps max. This is few, isn't it? Or is this always like this when using OpenCV with Java (over JNI) instead of c++?
Thanks in advance for any hints!
Isa
The next OpenCV version will fix a few camera bugs, maybe it fixes those messages. There is one specific to Nexus 7 2013, but looks different from yours.
JavaCamera is usually slower than NativeCamera but more stable (less buggy). But it also depends from other factors like ambient light (less light = slower), chosen resolution.
Recently my application received quite a lot comments that "it's not working" on Android Ice Cream Sandwich with CM9. I'm not able to reproduce the error on the emulator running Android 4.0 and thanks to the way android market works there's no way I can't contact those people to ask about the details.
Luckily, one crash error report caught my eye. I'm using Canvas.clipPath to draw rounded corners... and looks like some phones are throwing UnsupportedOperationException when trying to use that function. Quick look at Google reveals that it seems to be a problem when using hardware acceleration in Android 4.0 - so that's the potential reason of received comments.
The question is - what's going on? Weren't applications hardware accelerated in previous android versions? Why such common function isn't supported? What's the workaround?
Example usage of Canvas.clipPath can be found in my other post. Check the accepted answer here: Android rounded corners in ListView
Thanks in advance
In ICS, hardware acceleration was turned on by default. Until 4.0, the default was that hardware acceleration was off.
Hardware acceleration does not support clipPath (and a few other operations, see more here http://android-developers.blogspot.com/2011/03/android-30-hardware-acceleration.html)
I am facing the same issue. As a quick fix I will turn off acceleration for the entire application, and later I will rewrite the code not to use clipPath
You can turn off hardware acceleration only on the specific view that is causing problems. Check out my answer here: https://stackoverflow.com/a/14054331/596708