Just wanted to share an experience I had to see if anyone came across such issue, if they found the cause and more importantly how they fixed it.
The problem is pretty simple: while debugging native code on a Nexus 6, which as the Adreno 420 GPU, eglSwapBuffer could crash under certain circumstances when using Android 5.1 (5.0 worked perfectly).
Since I could not repro it I am unable to tell you what went wrong. According to the documentation, elgSwapBuffer calls internally glFlush; and so if I call glFlush before calling eglSwapBuffer all of a sudden it works perfectly.
My guess is that the driver does not flush properly thus crashing when swaping the buffers.
Any comments on this?
Cheers,
D
I'm having the same problem and I can reproduce it. It happens obviously because it runs out of stack memory due to deep nested loops in the rendering process.
Android Lollipop 5.1: Fatal signal 11 (SIGSEGV), code 2, fault addr 0x9e985ff8 in tid 4093 (RenderThread) / when using lot of nine patch graphics
I've already reported it to the google issue tracker:
https://code.google.com/p/android/issues/detail?id=163100
Update: Meanwhile I found a way to work around this issue. It's definitely not a long time solution, but for the moment, it's just the best available to stop my apps from crashing.
I disabled GPU rendering for particular graphic layers. It slows the drawing down a bit, but not significant.
So the nightmare is over for now, but I still think, this issue must be fixed on the driver itself. It cannot be that something that worked perfect with 5.0.2 and below, immediately stops to work with 5.1.
I have seen some weird behavior on the N6 as well, and while I cannot rule out app bugs, it looks to me like the Adreno driver is to blame.
Specifically, in landscape mode, our GLSurfaceView only renders one half of it's content, but occasionally flickers all of it. And with certain scenes being rendered there is intermittent flickering. In a case of extra weirdness, I have seen one half of the screen completely freeze, stuck on app content, even after returning to the launcher via the home button. It appears kind of like it would if it used multi stream transport and one of the streams was getting lost.
Related
First of all thanks for taking the time to read this question - we're thankful for any input/suggestions/thoughts.
In our Unity game, we're seeing a problem that we cannot solve for weeks. At random points in the game, the FPS drops to zero and nothing moves for 3-4 seconds, then everything gets updated in 1 frame as if the freeze has not happened. It seems it's a rendering problem because absolutely nothing goes wrong with the game's logic and functionalities, everything works as expected after the mini-freeze. Even the user's touches in that time window are processed afterward.
Clues:
Unity version: 2019.4.31f1
Optimized Frame Pacing: Disabled
Use incremental GC: Enabled
Target Architectures: ARMv7 + ARM64 built as an AAB file
Scripting Backend: IL2CPP
Graphics API: OpenGLES2
Application.targetFrameRate : 60
Vsync count: Don't Sync
Multithreaded Rendering: Enabled
Additional Information:
It is not a full freeze. New frames do get rendered if you wait long enough.
In the unity profiler we can see, that when the issue occurs the main thread seems to be waiting for "gfx.presentframe" on the render thread.
We could reproduce the issue on these devices: (All are 64-bit, Androids are 11 or 12)
Samsung Galaxy A30
Samsung S20 FE
Xiaomi Poco X3
Samsung A21s
Huawei Honor 50
Samsung S22 Ultra
Our problem is exactly like this Question, The difference is that in our game, Optimized Frame Pacing is already disabled, so disabling it cannot solve the issue for us.
Here's a Screenshot of the Unity profiler when this problem occurred, Look at the selected frame.
We are really stuck with the problem and any helpful thoughts or suggestions will make us smile! Thanks in Advance!
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 intermittently observing strange graphics artefacts in my app, as shown below. This is a screengrab from a Samsung Galaxy S3. I have only observed it on this particular phone. I have run the app on a Samsung Galaxy Tab S4 and an HTC One, and never observed this issue on either - although admittedly I do mainly use the S3 for development.
I considered that the issue might be some sort of concurrency clash in drawing to the Canvas (I'm using the basic Android rendering methods, no OpenGL or anything), since I can clearly recognise the repeating units of other UI elements, so I synchronized all the code which draws to or interacts with the Canvas and I'm still observing it happen.
It does clear itself up after around 30-90 seconds, which may be due to a regular scheduled memory cleanup operation it performs - so perhaps this is a manifestation of low available mem?
If I had enough rep I would stick a pretty big bounty on this. Any help appreciated. Hopefully someone recognises this particular problem.
Apply hardware layers:
setLayerType(View.LAYER_TYPE_HARDWARE, null);
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.
A while ago I bumped into an issue with eglSwapBuffers freezing the phone with the following message showing up in the device log:
W/SharedBufferStack( 1110): waitForCondition(LockCondition) timed out (identity=28, status=0). CPU may be pegged. trying again.
I've seen discussion on this issue all over the web but the only solution I've found to have any effect is calling glFinish after eglSwapBuffers. This solution, however, results in the framerate dropping by a whooping 10-20, which is far from acceptable.
Issues have been opened and one can be found here
Someone commented that using square textures eliminated the issue. By square I initially thought he meant power-of-two textures but after making sure I was not using any non-power-of-two textures and not getting rid of the issue I began to think that he might have actually meant textures with matching width and height?
I'm testing on an HTC Desire with Android 2.3.3. Someone commented that future versions should have fixed this issue but 2.3.3 is installed on so many devices that we can't disregard it.
Anyway, anyone have any thoughts on this? We're very close to shipping a title and this issue is threatening out schedule.
I also came across this issue, I used to re-install the Application and it worked for me.If not, then simply reboot your device.This issue is related to internal isssue of OpenGLES.You can refer this link:
Android "cpu may be pegged" bug