[android-developers] Re: TabActivity vs VideoView vs Camera Preview contention
I wouldn't be surprised if this doesn't work. :} On Wed, Dec 3, 2008 at 3:55 PM, Jason Proctor [EMAIL PROTECTED] wrote: hey all, i have TabActivity which does camera previews in one tab and has a VideoView in another. they don't get on very well - seems like each thinks it has control of the screen. in particular, once a preview has been done in the camera tab, then the VideoView tab has a black rectangle the size of the preview frame parked in the middle of it. i suspect that both facilities write direct to the frame buffer, and so some contention would be expected. is there any way round this? i'm setting the views' visibility accordingly in onTabChanged(), but it makes no difference, which i suspect is a bug. thanks for any help with this one j -- Dianne Hackborn Android framework engineer [EMAIL PROTECTED] Note: please don't send private questions to me, as I don't have time to provide private support. All such questions should be posted on public forums, where I and others can see and answer them. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -~--~~~~--~~--~--~---
[android-developers] Re: TabActivity vs VideoView vs Camera Preview contention
Assuming one of these is a surface view, it may be asking its parent container to be transparent so it can, as the docs say, punch a hole in the view hierarchy, since the surface is Z-ordered behind the native views. The parent here is the FrameLayout in the tab host that contains the tab content. You might try wrapping the view in a secondary frame layout to protect the real frame layout behind it. I haven't tried this. If it was your own views causing this, you could also override gatherTransparentRegion and return false. I have done this and it works. -- Ward hey all, i have TabActivity which does camera previews in one tab and has a VideoView in another. they don't get on very well - seems like each thinks it has control of the screen. in particular, once a preview has been done in the camera tab, then the VideoView tab has a black rectangle the size of the preview frame parked in the middle of it. i suspect that both facilities write direct to the frame buffer, and so some contention would be expected. is there any way round this? i'm setting the views' visibility accordingly in onTabChanged(), but it makes no difference, which i suspect is a bug. thanks for any help with this one j --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -~--~~~~--~~--~--~---
[android-developers] Re: TabActivity vs VideoView vs Camera Preview contention
but then tried subclassing it and returning false in gatherTransparentRegion() as you suggested. unfortunately this doesn't affect the behaviour - upon switching to the playback tab after a preview, the black rectangle remains. Well.poop. did i misunderstand your message? Nope. Unfortunately. (Though I am surprised, I had good luck with it.) Your proposed course of further hackery should work, but seems like such overkill. Wish I had a better answer. -- Ward --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -~--~~~~--~~--~--~---
[android-developers] Re: TabActivity vs VideoView vs Camera Preview contention
There could well be a bug here, nobody has done this kind of thing as far as I know, and the code for handling a SurfaceView is quite complicated and could easily have bugs in this area. So feel free to file a bug. That said, I can't make any promises about this being addressed any time soon, as there are probably many features and bugs that at this point have a significantly higher priority. If it is something that someone really wants to have fixed, the best way to get a result on it would probably be to debug the platform and submit a patch to fix it. :} (Which I know is asking a lot, because this IS very tricky code.) Oh one other thing, you might want to use hierarchyviewer just to make sure the state of your view hierarchy looks sane. On Wed, Dec 3, 2008 at 5:36 PM, Jason Proctor [EMAIL PROTECTED] wrote: i'm looking at the source for TabHost and it turns out that when a tab is selected, its view is set to visibility GONE. hence me setting it to INVISIBLE afterwards probably isn't helping! either way, i think making a SurfaceView GONE should probably stop it claiming chunks of screen and interfering with other views which are definitely VISIBLE. does the panel agree that this is a bug? -- Dianne Hackborn Android framework engineer [EMAIL PROTECTED] Note: please don't send private questions to me, as I don't have time to provide private support. All such questions should be posted on public forums, where I and others can see and answer them. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -~--~~~~--~~--~--~---
[android-developers] Re: TabActivity vs VideoView vs Camera Preview contention
I'm sure this is an artifact of the way we handle video overlays - they are treated differently than a regular surface. If I understand the behavior, I would agree that it's a bug. As a workaround, you will probably need to tear down the VideoView. For camera preview, you should be able to get away just clearing the preview surface. On Dec 3, 5:36 pm, Jason Proctor [EMAIL PROTECTED] wrote: i'm looking at the source for TabHost and it turns out that when a tab is selected, its view is set to visibility GONE. hence me setting it to INVISIBLE afterwards probably isn't helping! either way, i think making a SurfaceView GONE should probably stop it claiming chunks of screen and interfering with other views which are definitely VISIBLE. does the panel agree that this is a bug? --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -~--~~~~--~~--~--~---
[android-developers] Re: TabActivity vs VideoView vs Camera Preview contention
well, looks like the workaround isn't working. in onTabChange() between the list selector tab and the tab with the videoview in it, i call - videoTabView.addView (videoView); videoView.setVideoPath (path); videoView.start (); and i get just a black screen. also, even uninstalling the video view on an onTabChange() to the camera preview tab doesn't stop the (removed) video view overwriting the camera preview, so no previews after watching a video. what is the recommended way of tearing down a video view? tx j thanks for the response. i think the bug, tersely described, is that setting a SurfaceView's visibility to GONE (or indeed INVISIBLE) should probably release any hold on the screen. and yes -- my fix is to dynamically add and remove the relevant/offending views as their corresponding tabs become active and inactive etc. it's looking good but i'm seeing some side effects - calling VideoView.startPlayback() before the view is actually added to the layout results in no video. i'm trying to work around that ATM. I'm sure this is an artifact of the way we handle video overlays - they are treated differently than a regular surface. If I understand the behavior, I would agree that it's a bug. As a workaround, you will probably need to tear down the VideoView. For camera preview, you should be able to get away just clearing the preview surface. On Dec 3, 5:36 pm, Jason Proctor [EMAIL PROTECTED] wrote: i'm looking at the source for TabHost and it turns out that when a tab is selected, its view is set to visibility GONE. hence me setting it to INVISIBLE afterwards probably isn't helping! either way, i think making a SurfaceView GONE should probably stop it claiming chunks of screen and interfering with other views which are definitely VISIBLE. does the panel agree that this is a bug? --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -~--~~~~--~~--~--~---
[android-developers] Re: TabActivity vs VideoView vs Camera Preview contention
another quite alarming detail is that if i initially remove the video view from its tab in my activity's onCreate(), then that results in a black screen where the camera preview should be. if i leave the video view installed, then the preview works fine. this is somewhat baffling! --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -~--~~~~--~~--~--~---
[android-developers] Re: TabActivity vs VideoView vs Camera Preview contention
The black screen is probably the result of the 2D engine trying to composite from an empty camera preview frame buffer. The video push buffer surfaces were a late addition to SurfaceFlinger to facilitate the use of video hardware pipelines. I'm not surprised there are some rough edges because it didn't get any testing outside of the basic use cases. I suggest you log a bug. If you have a code snippet that demonstrates the problem, that would be even better. On Dec 3, 7:04 pm, Jason Proctor [EMAIL PROTECTED] wrote: another quite alarming detail is that if i initially remove the video view from its tab in my activity's onCreate(), then that results in a black screen where the camera preview should be. if i leave the video view installed, then the preview works fine. this is somewhat baffling! --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -~--~~~~--~~--~--~---
