Mark Zepeda
Mark Zepeda

Reputation: 11

Android xml:onclick from a layout with a glsurfaceview causes image drawables on previous activity to render as black

This is an odd problem that took me quite awhile to reproduce reliably.

I have a menu activity that is very simple; just some buttons defined in xml.

I have an activity with a layout with a GLSurfaceView and some buttons defined in xml. These buttons have onClick attributes defined. This activity is accessed from the menu activity.

In the OpenGL activity there are the associated onClick functions "onFoo(View view)".

When I navigate back to the menu activity using the native Back button nothing interesting happens; however, when I click ANY of the xml defined buttons with an onClick attribute and then navigate back some of the ImageViews on the menu activity appear as black but otherwise in their correct locations, sizes, etc. Their xml defined onClick functions work correctly as well.

I am having all of the images on the menu activity re-exported (to eliminate any export setting flaws since the assets were originally exported at various times), but while I wait for that to happen I figured maybe someone out there has run into this problem before.

For the purpose of limiting variables in this problem I even commented out the function's contents in the OpenGL activity to make sure nothing in the onClick functions was causing a conflict.

e.g.

public void onMainMenu (View view) { }

So, to clarify, if I click a button defined in xml with an onClick attribute e.g. android:onClick="onMainMenu" with the above empty method, then press the native back button the issue occurs, but not when skipping the clicking of the onMainMenu button.

I can't be sure if it is always the same set of ImageViews that turn black, but one ImageView does seem to consistently survive with the correct Drawable; this is odd because the ImageViews are defined identically other than their src attribute. They are all relatively the same size and not large at all.

I originally thought it had something to do with the EGL context (Android displays black rectangles instead of drawable images after opening openGL context) (and it still may be the case), but then I discovered how to reproduce it 100% of the time by pressing a button with an onClick attribute before navigating backwards. Memory usage is in control and I am lost for a possible solution or trail to one.

I can reproduce this on the three devices I have: an HTC One, Droid Bionic, Galaxy Tab 2 7.

The Application is minSdk:14, target:17. Hardware acceleration is on.

I tried playing with hardware acceleration settings with the following results:

If I turn off hardware acceleration for the application, and add it to just the OpenGl activity the main menu issue does not appear, but the same issue starts occurring in the OpenGL activity. In the case of this activity some ImageView's drawable resources are switched out at run-time. The switched in resources display correctly, but when switched back to the same resource that the was defined for that ImageView in xml it renders black.

To clarify the switching: in one such case I have views with a drawable-state-selector for their backgrounds. When switching between the two states (they function like tabs i.e. their default states as defined in xml are opposite) the default state always displays as black but the secondary state displays correctly.

If I turn off hardware acceleration for the application AND the OpenGL activity, the problem appears to go away completely.

I worry about using that as a solution though as I can't be sure of any performance problems that may occur on devices I do not have to test with.

Removing hardware acceleration from the OpenGL activity breaks a view that overlays the GLSurfaceView on at least the Droid Bionic, so I'd rather not use this pseudo-solution.

This is the first time I have posted a question on Stack Overflow. I always find a solid lead searching, but just could not find a solution or even a problem with similar circumstances in this case.

Thanks for any help and wisdom the community can provide!

Upvotes: 0

Views: 575

Answers (1)

Mark Zepeda
Mark Zepeda

Reputation: 11

The problem came down to a call to GLES20.glDeleteTextures(int size, int[] textureNames, int offset). I was calling this during onPause() which was somehow causing a conflict. I am not sure how it was related to touching a UI item outside of the GLSurfaceView. Removing the one call somehow prevents the issue.

Upvotes: 1

Related Questions