We're developing a custom Android application built for a specific Android -- formerly the Samsung Galaxy Tab 2 -- and I was pretty happy with the way it looked.
However, we've changed phones to the Nexus 7, and now a Text View that used to look fine blinks rapidly -- it's seizure inducing. My application updates the text a few times a second, but that's not new and we never had this problem with the Samsung.
Has anybody experienced something similar, or otherwise have a suggestion?? My original suspicion that the Samsung had more processor power is, I'm pretty sure, incorrect. Should I look into some of the Nexus' configuration details concerning rendering the GPU??
It's going to be annoying if have to get rid of this software feature, but I might have to if I can't improve the look.
It's not a great answer, but it does work for me if I set up my code to only update the text view every other trip through the draw loop. If anyone else has a different suggestion I'd certainly prefer to try something else, but this at least works.
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!
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.
This bug only occurs on my Nexus 5 and my Nexus 7 running Lollipop.
EDIT
This bug also occurs in the new Inbox app by Google, when I'm going into Inbox > Settings > Notifications > any item and go back...
/EDIT
compileSdkVersion 21
buildToolsVersion 21.1.1
compile 'com.android.support:appcompat-v7:21.0.2'
I'm having a GalleryActivity that shows multiple images, once per page (inside a ViewPager. When I hit the back button, sometimes the Android's SystemUI have glitches.
Normal view
Glitched view
See how the views repeats themselves, and inside the system itself?
A simple touch event brings back the normal SystemUI views.
What is going on?
Might be similar to:
Android 5 screen glitch/static with Google Maps Fragment inside a Viewpager
Android Lollipop Activity Screen corrupted
Setting android:hardwareAccelerated="false" is a kind of extreme solution, as graphical performance is likely to be very bad.
If you can pinpoint the view that is misbehaving and causing this issue, a better fix would be to switch it to software rendering instead, via setLayerType(), e.g.
view.setLayerType(View.LAYER_TYPE_SOFTWARE, null);
Funny thing is, I haven't experienced any rendering glitches with Lollipop so far, but we did see them in KITKAT (as mentioned in this question), and only when WebViews are present on the screen.
I would recommend experimenting with toggling this on different views until the problem is isolated (especially if it's easy to reproduce).
So far, every occurence of this issue has been related to WebViews (or components that use WebView, such as AdMob). According to the AOSP Issue Tracker the problem is fixed in Android 5.0, but it doesn't seem to be the case.
I've seen UI glitches with Lollipop, though different than yours. The only workaround I found was disabling hardware acceleration:
android:hardwareAccelerated="false"
at the Activity or Application level. If this resolves your glitches, make sure to report this to Google as this would indicate a bug in the platform. There is already at least one open report with them already.
I certainly wouldn't want to deploy an application with this setting, it's really only intended to answer the WHY and help prove that it's not a bug in your code.
Hope this helps!
EDIT 12/10/2014:
#matiash offered a much more precise answer than this "sledgehammer" suggestion. I was seeing drawing glitches mostly on the ActionBar in a multi-tab app with ViewPager, and always on tabs/pages without any WebView at all. However, one of my tabs/fragments does have an embedded WebView, and when setting it to software rendering, my glitches appear to have gone away. I'm not at all uncomfortable putting the workaround suggested by #matiash in a shipping app...though it still points to some underlying issue in the platform.
I have also witnessed this problem in my own app.
Any Android devs ever experience this kind of visual static? (see picture)
Not only did I get that kind of visual static, but also repeated drawing. Only witnessed it on Nexus 5 with 5.0 when developing with api 21 and support library 21.0.+.
For me its not very reproducible. It will happen repeatedly during one session of use, but the next day I won't be able to reproduce it.
I am not using any WebViews (accept maybe via admob). I am using ViewPagers with fragments. I am also using DragSortList and first started seeing the issue in Activities that used it.
https://github.com/bauerca/drag-sort-listview
How reproducible is it for you guys?
have you tried to set android:fitsSystemWindows="true" in your Fragment layout? this will make sure the layout is below the statusBar, im not really sure about the navigation buttons but i guess this should work for it too.
Call request layout on DecorView after rendering:
getActivity().getWindow().getDecorView().requestLayout();
I call it using postDelay() in WebViewClient.onPageFinished(). It's not a perfect solution (just a workaround) but maybe better way like LAYER_TYPE_SOFTWARE.
.........go to settings and then developer options(if they are not visible... go to about phone then click on build number 7-10 times and developer mode will be on) and there scroll down and untick 'show layout bounds' and you are done. its simple and easy.
I don't know if this applies to Android or iPhone. I have an Android 2.3.3 for testing and an iPod Touch 3rd generation with iOS 5 on the way. But I know its a problem on my buddy's new Blackberry.
Basically, my buddy has text zoom (or whatever you call it) turned on so that text is displayed at like 150% of its normal size on any web pages he views on his Blackberry. Well, I have optimized my sites with media queries so the text already increases to 150% on small screens. On his device, the device setting is compounded with my CSS settings and the text becomes absolutely enormous!
I'm sure this is a problem for a lot of users since there are so many sites out there with tiny text that has to be zoomed for mobile.
So my question is: Is there some kind of best practice approach or any solution to dealing with these folks that have turned on text-zoom or an equivalent feature? How can I make my text not be obscenely large and unuseable for them? Do I just leave it in their hands to turn the text zoom down?
Also, does Android 2.3 have some kind of feature like this that I should be testing for?
Thanks ahead.
I don't think there is a solution to cases where users have increased their text size. If someone knows of one, please indicate so. In the meantime, I DID find out that you can make device-specific adjustments for mobile devices with these:
-moz-text-size-adjust
-webkit-text-size-adjust
-ms-text-size-adjust
Details can be found here:
https://developer.mozilla.org/en-US/docs/CSS/text-size-adjust
I'm going to mark the question as answered since I don't believe a solution to the original issue actually exists at this time.
We have an HTML5-base app that's running in PhoneGap, using (mostly) jQuery for the components. Fairly regularly, the UI will be changed in javascirpt, but not completely render correctly. You kind of need to nudge it with another touch event, which causes it to "remember" to redraw everything. I suspect its some attempt to optimize the draw, but it forgets to update other parts of the screen that were changed.
I'm going to start modifying different css settings in the hope that it turns out to be some kind of simple bug, but I'm surprised that this isn't reported more widely (which makes me think this is due to a "magic combo" of css attributes).
So far the vast majority of testing has been on ICS. I don't have a 2.x device handy right now, but will try that tomorrow. My phone updated to Jelly Bean, so I'll try that and see if anything is different.
Will try to post a screenshot later.
Thanks in advance.
UPDATE
This works fine in Jelly Bean. I did a search in the public Android bug DB but nothing turned up. I'll have to dig out another phone with ICS on it and try different CSS settings and see if it goes away.