In one fragment in my app, I use a GLSurfaceView to render a 3d model. When this Fragment is visible, the user can navigate to another Fragment from it. While that Fragment transition happens, the whole GLSurfaceView turns black.
I started having this problem when I changed from setZOrderOnTop(true) to false. I understand the difference this makes, but It's not possible for me to use setZOrderOnTop(true) (I Have other Views and animations that needs to overlay the GLSurfaceView).
I have tried everything I could think of and everything related from Google searches, such as using backgrounds, hiding the view, replacing it with dummy view during transition etc. without any luck.
Does anyone have an idea how I can solve this?
Notes:
I must not use setZOrderOnTop(true)
I use Support Fragments
I'm currently testing this on a Sony xperia z3, running 6.0 marshmallow
The only time I have this issue is when transitioning from the fragment with the GLSurfaceView, not when I transition to it.
My Renderer uses glClear(..) to color render the whole view in a white color. My issue is not in the GL Code
Related
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!
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.
I'm working on a multimedia video processing application for Android, and I've run into a bit of a problem. I'm using the FragmentPagerAdapter class with a number of different fragments inside for various steps of video processing.
My first Fragment contains a SurfaceView and a MediaPlayer that feeds it, along with various playback controls. My problem happens when I swipe from fragment 1 (with the SurfaceView) to fragment 2 (empty at the moment). If I haven't yet called start(), nothing unusual happens, and I'm able to swipe between fragments normally. Once I call start() however, the entire screen starts flashing on and off when I swipe to the next Fragment, even if I've put the MediaPlayer in the idle state and it's not feeding frames to SurfaceView. The only thing that stops this is destroying the surface along with the containing view by swiping to the third Fragment so the FragmentPagerAdapter destroys Fragment one, or exiting the application via the home or back button so the view is destroyed.
I can't for the life of me figure out why this is happening, other than that perhaps the SurfaceView rendering thread is somehow interfering with the main UI thread. Nothing unusual appears on LogCat, either, so I'm a bit stuck. I'm running a Galaxy Nexus with android 4.1 as my test hardware.
Any help would be appreciated!
JT
UPDATE: I've managed to find a workaround for now by overriding the setPrimaryItem() method in the FragmentPagerAdapter to call a method that removes the SurfaceView from the hierarchy (using removeView() on its LinearLayout container) when the video player Fragment ceases to be displayed, and then reinstates the SurfaceView when it's active again. There's still a bit of a blink when this happens, unfortunately, so if anyone has additional thoughts, I'd be grateful!
From the Android Developers Blog
This widget[SurfaceView] works by creating a new window placed behind your application’s window. It then punches a hole through your application’s window to reveal the new window.
Because a SurfaceView’s content does not live in the application’s window, it cannot be transformed (moved, scaled, rotated) efficiently. This makes it difficult to use a SurfaceView inside a ListView or a ScrollView.
The Solution is to use a TextureView if you're building for 4.0 or above. If youre interested in using a TextureView to display video this thread might be helpful
In my project I am using a tab host. In one of the tabs there is a Fragment Activity with a Fragment that includes an ImageView with some transparent regions as a background.
Now, in another tab I am incl. the (modified) CaptureActivity of the ZXing QR-Scanner library. I already went through all the hustle of making it work in portrait mode. My issue is, that when I open that one fragment mentioned above (and only in that specific case and order) before the CaptureActivity, the CaptureActivity's layout gets screwed up. The background image of the fragment is shown (although not incl. in this layout) and the camera preview is only shown in the transparent areas, see below.
Now, I don't know if that has to do with the surface view included here.
Somehow it seems to not only be a drawing / clipping issue, because the textview you can see is drawn on top of the surfaceview and is actually orientated android:layout_gravity="bottom|center_horizontal" (and works that way in every other case), but when this issue occurs the textview seems to be getting aligned within the other fragment layout that incl. the partially transparent background imageview.
Any hints are really appreciated. I can post some code if I have a lead what might be the problem here.
Thanks!
In the end I could solve the issue by renaming the drawable-png used as a drawable of the background imageview. Although I checked this before, I don't know if there was a mixup in the ids with the library or maybe I hit some kind of bug.
I'm trying to start an activity and create the transition as a 3d flip (as many have stated exactly like on the IPhone), unfortunately I haven't found a satisfying answer yet and I am stuck.
I've implemented http://www.inter-fuser.com/2009/08/android-animations-3d-flip.html
for the whole layout so that now when pressing a certain button the layouts are flipped, but since it refers to layout that are in activities which weren't loaded, they don't fill all their items and data (an expandable list view for example).
But when i call startActivity() after the flip the activity is created which of course hides the framelayout container on the caller activity - so i can't flip back... (I've used the overridePendingTransition but imho it shouldn't matter).
I could really use your help am losing my mind...
Thanks!
Sorry you can't do this -- the window manager currently only supports 2d animations.
I also want to flip activity as 3D animation. I just found this solution http://blog.robert-heim.de/karriere/android-startactivity-rotate-3d-animation-activityswitcher/
What they does.. startActivity with no animation any apply 3D rotation on it.
In the Honeycomb sample gallery app, there's a layout that uses a two-fragment setup: one on the left of the screen showing titles, and one on the right showing the selected content. The titles fragment can be hidden with an animation.
During the hiding animation, the app asks the framework to recalculate the layout on every single frame. This way the content-fragment can take up the empty space that the titles-fragment leaves behind while it moves off-screen. This produces a great, dynamic effect, but is terribly inefficient I think.
I have fairly complex layouts, and I'd rather not ask the system to re-layout on every single frame. But I'd like a smooth transition animation like in the sample. Are there any alternative solutions to this problem?
P.s.: Just to be clear, I'm not asking how to do basic fragment-transaction animations. I know those, and AFAIK, those animations can't produce the behaviour found in that sample gallery app (another example would be the Honeycomb Gmail app, it has similar transitions that I'd like to achieve).
You can provide custom animations to the fragment system that do whatever you want. You can move the fragments around, fade them, etc. If these animations do not explicitly or implicitly cause layout (by changing properties that trigger a layout), then you should not get a layout on each animation frame. There maybe still be a layout call at the beginning/end as the fragments are added/removed, but the layout/invalidation process during the animation is up to your animations and what they do.