0

I'm using opengl es 3.0 API with the android studio ndk to create apps. But I've encountered a very huge problem. I've created a demo app, all it does it change the background color of the screen from white to black and vice versa, every frame. And so when I go to minimize this app, I still see it rendering the background, mostly at the edges of the screen, and not in full color but still very strongly apparent. And it doesn't go away when I close the app, when I restart the device, or when I run "kill apps" on it. Only a factory data reset fixes the issue, so it's not easy for me to debug this.

This is the relevant code that I'm using for when the app is minimized and receives the APP_CMD_TERMINATE event:

eglMakeCurrent(engine->display,EGL_NO_SURFACE,EGL_NO_SURFACE,EGL_NO_CONTEXT);
eglDestroySurface(engine->display,engine->surface);
engine->display = EGL_NO_DISPLAY;
engine->surface = EGL_NO_SURFACE;

I've error checked that eglDestroySurface() is successful. And I've put debugging messages in to make sure that the main draw loop is NOT executing when the app is minimized. But the problem persists and I don't know what to do about it. Thanks for any help.

UPDATE: well, no one has responded, and I still don't know what to do. Could it be related to threads?

UPDATE: Still can't determine what it is, but for some reason it's messing with the System UI. Willing to upload my entire source code somewhere if someone would be willing to go through this with me, as I'd really like to be able to continue working on my game engine.

cyb3rcolby
  • 53
  • 7
  • Does `APP_CMD_TERMINATE` exist? Google finds nothing. – Columbo Sep 16 '19 at 18:34
  • APP_CMD_TERM_WINDOW. pardon me. – cyb3rcolby Sep 16 '19 at 23:26
  • Sounds like an OS issue to me. There's nothing an app should be able to do that should mess up rendering even after the app is killed. Is there an OS update available? Is there another device you can test on? If you're testing on some sort of simulator, can you switch to device or at least update the simulator, OS and the PC's graphics drivers? – Columbo Sep 17 '19 at 08:42
  • I have tested on 3 devices. 2 tablets and 1 phone. It does it on both tablets, but not the phone. Go figure. – cyb3rcolby Sep 17 '19 at 10:22
  • The phones on 8.X, one tablet is on 7.X and the kindle fire is on 5.X – cyb3rcolby Sep 17 '19 at 10:24
  • Well, I factory reset my tablets and reran it, and it wasn't doing it. So I set it to my scene demo, which is using glMapBufferRange and it is doing it again. – cyb3rcolby Sep 17 '19 at 10:39
  • From the docs: OpenGL and OpenGL ES buffer mappings created by e.g. glMapBuffer are not affected by eglMakeCurrent; they persist whether the context owning the buffer is current or not. If draw is destroyed after eglMakeCurrent is called, then subsequent rendering commands will be processed and the context state will be updated, but the surface contents become undefined. – cyb3rcolby Sep 17 '19 at 10:53
  • This sounds like what's happening to me, but what's the solution for it? – cyb3rcolby Sep 17 '19 at 10:54
  • sadly, it's still doing it even when im not using glMapBufferRange() – cyb3rcolby Sep 17 '19 at 17:45
  • Update: the issue persists even when I do eglTerminate() on all minimization, so I assume it's something about the setup process? – cyb3rcolby Sep 20 '19 at 03:41

2 Answers2

0

Is it the "Strict Mode" developer option on the device settings, perhaps?

That one flashes the screen if an app is blocking.

It would explain why a factory reset changes behaviour.

enter image description here

Bram
  • 7,440
  • 3
  • 52
  • 94
  • No. It's not turned on. It s less a flag than an imprint of what was being rendered. Sometimes it'll go away on it's own but it's worse the longer I leave my app running. Worst around the edges. – cyb3rcolby Sep 17 '19 at 19:46
  • A screenshot would help, or a photograph. – Bram Sep 17 '19 at 19:58
  • https://imgur.com/xWeUXw5 this is what happens when i render a black and white checkerboard, but flipping black from white and white to black every frame. it also ghosts like this if i just flip the background color from white to black and black to white every frame, not even drawing anything. I had to take a photograph because screen shots didnt pick up the ghosting effect! My two tablets do this, but my phone is immune for some reason. – cyb3rcolby Sep 17 '19 at 21:36
  • This issue sounds crazy - could it be some sort of artifact of the lcd display itself? I don't know much about lcds, but it's kind of a pathological case for them when you flick from full-black to full-white at 60fps. Do you see similar issues if you change it to use light-grey/dark-grey? e.g. 0x606060/0xa0a0a0 – Columbo Sep 18 '19 at 09:55
  • those colors are doing it, as well, but i had to leave the app running longer for it to happen. but what you say, it makes sense because my phone, the one device it doesn't do it on, is called an "OLED or Super AMOLED" screen, but the other two are lcd. yet on the other hand, doesn't this seem like kind of an issue a person would have encountered, that people would know about? it doesn't seem right at all. – cyb3rcolby Sep 18 '19 at 10:43
0

The answer is not a solution here. The above comment by the user columbo was correct. I've demoed switching from black to white at high framerates on 3 different android devices, and also my Linux Desktop, all via the openGL api, and it has exhibited this issue on all the devices. So what he said must be correct: this is a problem with LCD monitor technology itself. Interestingly, doing completely random colors does not cause this problem.

cyb3rcolby
  • 53
  • 7