[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 -~--~~~~--~~--~--~---
[android-developers] Re: TabActivity vs VideoView vs Camera Preview contention
Are you accessing the MediaPlayer object from two threads? There isn't a lot of code on the application side and it seems suspicious that it would be crashing there. We did try to make it thread-safe, but it's possible we missed an edge case. On Dec 6, 3:31 pm, Jason Proctor <[EMAIL PROTECTED]> wrote: > logged as bug 1464. > > i replaced the VideoView with a combination of SurfaceView and > manually installed MediaPlayer. this combination has worked for me in > other applications, but in this particular instance, calling > MediaPlayer.prepare() causes a VM crash -- > > 12-06 15:30:09.837: INFO/DEBUG(826): *** *** *** *** *** *** *** *** > *** *** *** *** *** *** *** *** 12-06 15:30:09.837: INFO/DEBUG(826): > Build fingerprint: > 'tmobile/kila/dream/trout:1.0/TC4-RC30/116143:user/ota-rel-keys,release-keys' > 12-06 15:30:09.837: INFO/DEBUG(826): pid: 882, tid: 882 >>> > com.particlebrand.uooo.android <<< 12-06 15:30:09.837: > INFO/DEBUG(826): signal 11 (SIGSEGV), fault addr 000c 12-06 > 15:30:09.837: INFO/DEBUG(826): r0 bef9d5dc r1 0001 r2 a6d8 > r3 12-06 15:30:09.837: INFO/DEBUG(826): r4 000c r5 > bef9d5d8 r6 bef9d5a8 r7 bef9d578 12-06 15:30:09.837: > INFO/DEBUG(826): r8 bef9d630 r9 4104dd6c 10 4104dd58 fp > 12-06 15:30:09.837: INFO/DEBUG(826): ip a9d45784 sp bef9d568 lr > a9d25303 pc ab218752 cpsr 8030 12-06 15:30:09.907: > INFO/DEBUG(826): #00 pc ab218752 /system/lib/libmedia.so > 12-06 15:30:09.907: INFO/DEBUG(826): #01 pc ab215abe > /system/lib/libmedia.so 12-06 15:30:09.917: INFO/DEBUG(826): > #02 pc ab302ea8 /system/lib/libmedia_jni.so 12-06 15:30:09.917: > INFO/DEBUG(826): #03 pc ad00d9f4 /system/lib/libdvm.so > i'm starting to think that having both camera preview and video in > the same tab activity is just destined for failure. i really hope not. > > tx > j > > >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 -~--~~~~--~~--~--~---