I'm moving my app away from NativeActivity because I want to do more things on the Java side and less things in C. However, I still want to keep the renderer in C. That's why I'm using an Activity which has a SurfaceView as its main view.
When I used NativeActivity, ANativeWindow_getFormat() returned RGBX_8888 which was just fine. With my new renderer based on SurfaceView, however, my surfaceChanged() callback always receives RGB_565 as the pixel format which looks really ugly because it only has 65536 colors and gradients look pretty cheap in 16 bits.
So I tried to add the following code to my Activity's onCreate() before calling setContentView():
getWindow().setFormat(PixelFormat.RGBX_8888);
This indeed solves the problem on my Nexus 5X device running Android 8 but on my Nexus 9 tablet running Android 7 it doesn't work and I still get 16-bit surfaces.
What is confusing me, however, is the fact that when using NativeActivity on my Nexus 9 tablet running Android 7 I actually get RGBX_8888 surfaces! So this definitely is not a hardware/system limitation on Nexus 9/Android 7. It works for NativeActivity, but not for my SurfaceView.
What is even more confusing is that when peeking into the Android source codes, you can see that NativeActivity actually explicitly request RGB_565 in its onCreate (see here) but still I get RGBX_8888 when I call ANativeWindow_getFormat() on my Nexus 9/Android 7. This is of course fine with me but of course it makes me wonder where the RGBX_8888 surface actually comes from because NativeActivity requests a RGB_565 surface.
To cut a long story short: Basically, all I need to know is how I can force my SurfaceView to use a RGBX_8888 surface on my Nexus 9/Android 7. On my Nexus 5X/Android 8 the code shown above does the trick but it doesn't work on the Nexus 9. But since NativeActivity can do it on the Nexus 9, it must be possible on this device as well. I just don't know how.
For the record, I was able to solve this by setting EGL_RED_SIZE, EGL_GREEN_SIZE and EGL_BLUE_SIZE to 8 when calling eglChooseConfig() on the native side.
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!
I'm using a barcode scanner library wich uses a camera layout, the usual. I tried the library on three devices and it looks fine in all of them.
But in the fourth device, it looks like this.
I uploaded pictures instead screenshots because, when you make one, the bug doesn't appears on it. It just looks normal. This makes me think about some kind of GPU/Android bug or something like that, but I really don't know where this is coming from and how to fix it.
By the way, the devices I used testing are: Nexus 5 (6.0.1), Galaxy Young (4.1.2) and Doogee DG685 (4.2.2). In all of them the layout is perfectly showed. The bug only appears on a HoneyWell E70 (4.0.3).
Author has explained to me that it's caused by using SurfaceView instead of SurfaceTexture.
The library has a XML attribute to fix it:
app:zxing_use_texture_view="true"
But it's not documented. In the next release this option will be true by default.
I'm developing an app. This app has an layout. The layout is fairly simple. To make it even simpler, let's say that the layout consists of TextView and CustomView. The purpose of this custom view is drawing a large bitmap (1080 x 700).
In CustomView I store an integer for image resource. In its constructor I'm executing an AsyncTask to start decompressing resource. When decompressing finishes the CustomView is invalidated. In draw method I'm checking if bitmap hasn't already been decompressed then it does nothing, if bitmap is decompressed then the CustomView is drawing it and freeing it resources.
So far so good :)
I have test devices:
1. ZTE blade III - 1GHz single core, 512MB RAM, running android 4.0.4 (API 15)
2. HTC Desire X - 1GHz single core, 1GB RAM, running android 4.1.1 (API 16)
3. HTC Sensation 1.5 GHz dual core, 768MB RAM, running android 4.4.4 (API 19, rooted)
4. Google Nexus 5, 2.27GHZ quad-core, 2GB RAM, running android 5.0.1 (API 21)
At the time of developing I was testing on device 1, because it should be the slowest and if there everything is OK, so it would be OK everywhere else. And yes the approach from above worked well on this device.
Then I tried to device 2 - everything was as expected.
Then device 3 - again everything is good. On this device I run "Profile GPU rendering" to see how good it really is. Most of the time the bars are below green line, just when the bitmap is showing on the screen, they are higher and dropping fps from 60+ to around 30, which is good again. First of all I thought that canvas.drawBitmap() is slow, but when I check it the results was - less than 1ms for executing canvas.drawBitmap(). I checked again bars from "Profile GPU rendering". The blue and orange onces were low and yellow was above green line. Then I checked what does these colors mean http://developer.android.com/about/versions/jelly-bean.html. The yellow one is for "waiting commands to complete" - so everything looks good.
On 4th device I was expecting the best performance, but....no. Here the entire UI thread is freezing when the bitmap have to be shown on screen. I run again "Profile GPU rendering". Here for my great surprise are 4 colors. The 3 from above and purple one. At the time when bitmap is shown on the screen and UI thread freezes exactly the purple bar is from bottom to top of the screen so I see only tiny blue and HUGE purple bar. I try to see what is that bar for and found that is mean "prepare" - https://android.stackexchange.com/questions/89017/what-does-purple-colour-mean-in-gpu-rendering-profiling.
So finally my question is what am I missing for drawing bitmaps for lollipop and why this prepare stage takes so long when drawing bitmaps? Is It connected to lollipop or to Nexus 5? It is impossible for Google to add new stage which slows down the UI pipeline
UPDATE:
So after a lot of testing I realized that I have missed something :)
Really stupid that I didn't realized it earlier, but.... :(
As I said the app is still under developing and because of that I am making just a single drawable and putting it inside drawable-nodpi folder. But in this case I put it in wrong folder, instead of drawable-nodpi, I put it in drawable. This was causing Nexus 5 to decode it 9 times large bitmap and this was causing slowness.
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.
Im testing my new game prior to release and i have found that on some devices the Z positions seemed to be mixed up in some cases and objects that should appear on top were appearing underneath.
I'm running opengl es 1 and it runs perfectly on my Samsung Galaxy S2 (and all the samsung devices i tested on) but went wrong on a HTC Desire.
Does anyone have any ideas?
Can you provide us with some pictures and source code? Common depth buffer problems cause some banding problems but your problem seems more related to some default driver state that is set differently value depending on which hardware are you running on.
I suggest you to generate a very simple example and start from the scratch until you find where is the problem, I don't think we can help you with so little information.
Hope that helps.