I am currently working on an app that requires computations/rendering based on a variety of user inputs. I have implemented the SurfaceView and things work as expected. But I started facing performance issues when I tried to put this inside a horizontal scroll view. Obviously it is not intended to work this way - but I tried anyway :) Based on what I have read - it appears like I have to move to TextureView. But i am unable to override the onDraw, and therefore cannot perform the necessary drawing using the Canvas. This might be a trivial question - but I wanted to know if we can use TextureView to draw primitives on the screen using a Canvas? The only examples I have seen thus far show the use of video/camera/openGL rendering on the TextureView.
If you were using SurfaceView's onDraw() method then you were not
getting any benefit. You have to use
lockCanvas()/unlockCanvasAndPost() and post on the underlying Surface.
TextureView works in a similar way: you can call
lockCanvas()/unlockCanvasAndPost().
However, it seems all you need is a View. It's easier to use and since
you are not using SurfaceView properly anyway it will do the same
thing.
On Thu, Sep 27, 2012 at 2:19 PM, Ajit Vasudevan <vasu.a...@gmail.com> wrote:
> Hello,
> I am currently working on an app that requires computations/rendering based
> on a variety of user inputs. I have implemented the SurfaceView and things
> work as expected.
> But I started facing performance issues when I tried to put this inside a
> horizontal scroll view. Obviously it is not intended to work this way - but
> I tried anyway :)
> Based on what I have read - it appears like I have to move to TextureView.
> But i am unable to override the onDraw, and therefore cannot perform the
> necessary drawing using the Canvas. This might be a trivial question - but I
> wanted to know if we can use TextureView to draw primitives on the screen
> using a Canvas? The only examples I have seen thus far show the use of
> video/camera/openGL rendering on the TextureView.
> Any help on this would be great.
> Thanks much
> -Ajit
> --
> 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
> android-developers+unsubscribe@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/android-developers?hl=en
-- Romain Guy
Android framework engineer
romain...@android.com
I was experiencing a very interesting behavior. I started using a custom view inside a framelayout, and performed all the primitive operations and called invalidate() to let the system call onDraw. It was choking. I even tried to invalidate a rect, but it was just not fast enough - the 2nd view that was requesting the underlying view to redraw certain primitives based on the actions on the 2nd view was not responsive. I then started using the SurfaceView to see if there is any benefit for the same operation - and voila - it worked like a charm. This is why is used SurfaceView as a substitute - there was an apparent performance benefit.
That said, I'm going to take another look at my hierarchy, and all the custom views (there are quite a few), to make sure there are no other leaks. Like you said, I would rather use a View instead of SurfaceView. Thanks for your input though - it does answer the question that I can use a canvas with TextureView if i follow the intended mode of use.
On Saturday, September 29, 2012 2:47:45 PM UTC-7, Romain Guy (Google) wrote:
> Hi,
> If you were using SurfaceView's onDraw() method then you were not > getting any benefit. You have to use > lockCanvas()/unlockCanvasAndPost() and post on the underlying Surface. > TextureView works in a similar way: you can call > lockCanvas()/unlockCanvasAndPost().
> However, it seems all you need is a View. It's easier to use and since > you are not using SurfaceView properly anyway it will do the same > thing.
> On Thu, Sep 27, 2012 at 2:19 PM, Ajit Vasudevan <vasu...@gmail.com<javascript:>> > wrote: > > Hello,
> > I am currently working on an app that requires computations/rendering > based > > on a variety of user inputs. I have implemented the SurfaceView and > things > > work as expected. > > But I started facing performance issues when I tried to put this inside > a > > horizontal scroll view. Obviously it is not intended to work this way - > but > > I tried anyway :) > > Based on what I have read - it appears like I have to move to > TextureView. > > But i am unable to override the onDraw, and therefore cannot perform the > > necessary drawing using the Canvas. This might be a trivial question - > but I > > wanted to know if we can use TextureView to draw primitives on the > screen > > using a Canvas? The only examples I have seen thus far show the use of > > video/camera/openGL rendering on the TextureView.
> > Any help on this would be great.
> > Thanks much > > -Ajit
> > -- > > You received this message because you are subscribed to the Google > > Groups "Android Developers" group. > > To post to this group, send email to android-d...@googlegroups.com<javascript:> > > To unsubscribe from this group, send email to > > android-developers+unsubscribe@googlegroups.com <javascript:> > > For more options, visit this group at > > http://groups.google.com/group/android-developers?hl=en
There is an overhead associated to invalidate() but unless your
hierarchy is extremely complicated it shouldn't be such an issue. But
you're right: SurfaceView can be used to avoid calling invalidate()
but don't override it's onDraw() method. You usually create a new
thread that renders onto the surface.
On Mon, Oct 1, 2012 at 2:53 AM, Ajit Vasudevan <vasu.a...@gmail.com> wrote:
> Hi Romain,
> Thanks for your response.
> I was experiencing a very interesting behavior. I started using a custom
> view inside a framelayout, and performed all the primitive operations and
> called invalidate() to let the system call onDraw. It was choking. I even
> tried to invalidate a rect, but it was just not fast enough - the 2nd view
> that was requesting the underlying view to redraw certain primitives based
> on the actions on the 2nd view was not responsive. I then started using the
> SurfaceView to see if there is any benefit for the same operation - and
> voila - it worked like a charm. This is why is used SurfaceView as a
> substitute - there was an apparent performance benefit.
> That said, I'm going to take another look at my hierarchy, and all the
> custom views (there are quite a few), to make sure there are no other leaks.
> Like you said, I would rather use a View instead of SurfaceView. Thanks for
> your input though - it does answer the question that I can use a canvas with
> TextureView if i follow the intended mode of use.
> -Ajit
> On Saturday, September 29, 2012 2:47:45 PM UTC-7, Romain Guy (Google) wrote:
>> Hi,
>> If you were using SurfaceView's onDraw() method then you were not
>> getting any benefit. You have to use
>> lockCanvas()/unlockCanvasAndPost() and post on the underlying Surface.
>> TextureView works in a similar way: you can call
>> lockCanvas()/unlockCanvasAndPost().
>> However, it seems all you need is a View. It's easier to use and since
>> you are not using SurfaceView properly anyway it will do the same
>> thing.
>> On Thu, Sep 27, 2012 at 2:19 PM, Ajit Vasudevan <vasu...@gmail.com> wrote:
>> > Hello,
>> > I am currently working on an app that requires computations/rendering
>> > based
>> > on a variety of user inputs. I have implemented the SurfaceView and
>> > things
>> > work as expected.
>> > But I started facing performance issues when I tried to put this inside
>> > a
>> > horizontal scroll view. Obviously it is not intended to work this way -
>> > but
>> > I tried anyway :)
>> > Based on what I have read - it appears like I have to move to
>> > TextureView.
>> > But i am unable to override the onDraw, and therefore cannot perform the
>> > necessary drawing using the Canvas. This might be a trivial question -
>> > but I
>> > wanted to know if we can use TextureView to draw primitives on the
>> > screen
>> > using a Canvas? The only examples I have seen thus far show the use of
>> > video/camera/openGL rendering on the TextureView.
>> > Any help on this would be great.
>> > Thanks much
>> > -Ajit
>> > --
>> > You received this message because you are subscribed to the Google
>> > Groups "Android Developers" group.
>> > To post to this group, send email to android-d...@googlegroups.com
>> > To unsubscribe from this group, send email to
>> > android-developers+unsubscribe@googlegroups.com
>> > For more options, visit this group at
>> > http://groups.google.com/group/android-developers?hl=en
> --
> 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
> android-developers+unsubscribe@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/android-developers?hl=en
-- Romain Guy
Android framework engineer
romain...@android.com
I have a similar problem but I was using SurfaceView properly as you mention Romain Guy but changing my code over does not work. The problem and code was posted here http://stackoverflow.com/questions/12688409/android-textureview-canva... The unlockandpostcanvas method does nothing. neither does TextureView.invalidate or surface.updateTexImage(). Only tapping the screen gets it to display?? Any ideas?
On Monday, 1 October 2012 18:17:57 UTC+2, Romain Guy (Google) wrote:
> There is an overhead associated to invalidate() but unless your > hierarchy is extremely complicated it shouldn't be such an issue. But > you're right: SurfaceView can be used to avoid calling invalidate() > but don't override it's onDraw() method. You usually create a new > thread that renders onto the surface.
> On Mon, Oct 1, 2012 at 2:53 AM, Ajit Vasudevan <vasu...@gmail.com<javascript:>> > wrote: > > Hi Romain,
> > Thanks for your response.
> > I was experiencing a very interesting behavior. I started using a custom > > view inside a framelayout, and performed all the primitive operations > and > > called invalidate() to let the system call onDraw. It was choking. I > even > > tried to invalidate a rect, but it was just not fast enough - the 2nd > view > > that was requesting the underlying view to redraw certain primitives > based > > on the actions on the 2nd view was not responsive. I then started using > the > > SurfaceView to see if there is any benefit for the same operation - and > > voila - it worked like a charm. This is why is used SurfaceView as a > > substitute - there was an apparent performance benefit.
> > That said, I'm going to take another look at my hierarchy, and all the > > custom views (there are quite a few), to make sure there are no other > leaks. > > Like you said, I would rather use a View instead of SurfaceView. Thanks > for > > your input though - it does answer the question that I can use a canvas > with > > TextureView if i follow the intended mode of use.
> > -Ajit
> > On Saturday, September 29, 2012 2:47:45 PM UTC-7, Romain Guy (Google) > wrote:
> >> Hi,
> >> If you were using SurfaceView's onDraw() method then you were not > >> getting any benefit. You have to use > >> lockCanvas()/unlockCanvasAndPost() and post on the underlying Surface. > >> TextureView works in a similar way: you can call > >> lockCanvas()/unlockCanvasAndPost().
> >> However, it seems all you need is a View. It's easier to use and since > >> you are not using SurfaceView properly anyway it will do the same > >> thing.
> >> On Thu, Sep 27, 2012 at 2:19 PM, Ajit Vasudevan <vasu...@gmail.com> > wrote: > >> > Hello,
> >> > I am currently working on an app that requires computations/rendering > >> > based > >> > on a variety of user inputs. I have implemented the SurfaceView and > >> > things > >> > work as expected. > >> > But I started facing performance issues when I tried to put this > inside > >> > a > >> > horizontal scroll view. Obviously it is not intended to work this way > - > >> > but > >> > I tried anyway :) > >> > Based on what I have read - it appears like I have to move to > >> > TextureView. > >> > But i am unable to override the onDraw, and therefore cannot perform > the > >> > necessary drawing using the Canvas. This might be a trivial question > - > >> > but I > >> > wanted to know if we can use TextureView to draw primitives on the > >> > screen > >> > using a Canvas? The only examples I have seen thus far show the use > of > >> > video/camera/openGL rendering on the TextureView.
> >> > Any help on this would be great.
> >> > Thanks much > >> > -Ajit
> >> > -- > >> > You received this message because you are subscribed to the Google > >> > Groups "Android Developers" group. > >> > To post to this group, send email to android-d...@googlegroups.com > >> > To unsubscribe from this group, send email to > >> > android-developers+unsubscribe@googlegroups.com <javascript:> > >> > For more options, visit this group at > >> > http://groups.google.com/group/android-developers?hl=en
> > -- > > You received this message because you are subscribed to the Google > > Groups "Android Developers" group. > > To post to this group, send email to android-d...@googlegroups.com<javascript:> > > To unsubscribe from this group, send email to > > android-developers+unsubscribe@googlegroups.com <javascript:> > > For more options, visit this group at > > http://groups.google.com/group/android-developers?hl=en
On Wednesday, 3 October 2012 11:34:58 UTC+2, Conrad Chapman wrote:
> I have a similar problem but I was using SurfaceView properly as you > mention Romain Guy but changing my code over does not work. The problem and > code was posted here
> On Monday, 1 October 2012 18:17:57 UTC+2, Romain Guy (Google) wrote:
>> There is an overhead associated to invalidate() but unless your >> hierarchy is extremely complicated it shouldn't be such an issue. But >> you're right: SurfaceView can be used to avoid calling invalidate() >> but don't override it's onDraw() method. You usually create a new >> thread that renders onto the surface.
>> On Mon, Oct 1, 2012 at 2:53 AM, Ajit Vasudevan <vasu...@gmail.com> >> wrote: >> > Hi Romain,
>> > Thanks for your response.
>> > I was experiencing a very interesting behavior. I started using a >> custom >> > view inside a framelayout, and performed all the primitive operations >> and >> > called invalidate() to let the system call onDraw. It was choking. I >> even >> > tried to invalidate a rect, but it was just not fast enough - the 2nd >> view >> > that was requesting the underlying view to redraw certain primitives >> based >> > on the actions on the 2nd view was not responsive. I then started using >> the >> > SurfaceView to see if there is any benefit for the same operation - and >> > voila - it worked like a charm. This is why is used SurfaceView as a >> > substitute - there was an apparent performance benefit.
>> > That said, I'm going to take another look at my hierarchy, and all the >> > custom views (there are quite a few), to make sure there are no other >> leaks. >> > Like you said, I would rather use a View instead of SurfaceView. >> Thanks for >> > your input though - it does answer the question that I can use a canvas >> with >> > TextureView if i follow the intended mode of use.
>> > -Ajit
>> > On Saturday, September 29, 2012 2:47:45 PM UTC-7, Romain Guy (Google) >> wrote:
>> >> Hi,
>> >> If you were using SurfaceView's onDraw() method then you were not >> >> getting any benefit. You have to use >> >> lockCanvas()/unlockCanvasAndPost() and post on the underlying Surface. >> >> TextureView works in a similar way: you can call >> >> lockCanvas()/unlockCanvasAndPost().
>> >> However, it seems all you need is a View. It's easier to use and since >> >> you are not using SurfaceView properly anyway it will do the same >> >> thing.
>> >> On Thu, Sep 27, 2012 at 2:19 PM, Ajit Vasudevan <vasu...@gmail.com> >> wrote: >> >> > Hello,
>> >> > I am currently working on an app that requires >> computations/rendering >> >> > based >> >> > on a variety of user inputs. I have implemented the SurfaceView and >> >> > things >> >> > work as expected. >> >> > But I started facing performance issues when I tried to put this >> inside >> >> > a >> >> > horizontal scroll view. Obviously it is not intended to work this >> way - >> >> > but >> >> > I tried anyway :) >> >> > Based on what I have read - it appears like I have to move to >> >> > TextureView. >> >> > But i am unable to override the onDraw, and therefore cannot perform >> the >> >> > necessary drawing using the Canvas. This might be a trivial question >> - >> >> > but I >> >> > wanted to know if we can use TextureView to draw primitives on the >> >> > screen >> >> > using a Canvas? The only examples I have seen thus far show the use >> of >> >> > video/camera/openGL rendering on the TextureView.
>> >> > Any help on this would be great.
>> >> > Thanks much >> >> > -Ajit
>> >> > -- >> >> > You received this message because you are subscribed to the Google >> >> > Groups "Android Developers" group. >> >> > To post to this group, send email to android-d...@googlegroups.com >> >> > To unsubscribe from this group, send email to >> >> > android-developers+unsubscribe@googlegroups.com >> >> > For more options, visit this group at >> >> > http://groups.google.com/group/android-developers?hl=en
>> > -- >> > You received this message because you are subscribed to the Google >> > Groups "Android Developers" group. >> > To post to this group, send email to android-d...@googlegroups.com >> > To unsubscribe from this group, send email to >> > android-developers+unsubscribe@googlegroups.com >> > For more options, visit this group at >> > http://groups.google.com/group/android-developers?hl=en
@Romain : I fixed a rather expensive draw operation on the canvas in one of my views (a custom listview actually - was performing a few primitive draws in the onDraw method). I managed to define a Rect area to limit the bounds. It opens up another question - but I will post it in a separate thread because its not related to TextureView. FYI - Once i fixed this , a simple view (with invalidate() calls) worked like a charm - atleast thus far. I will gauge the performance and see if introducing more drawing operations causes it to choke.
> On Wednesday, 3 October 2012 11:34:58 UTC+2, Conrad Chapman wrote:
>> I have a similar problem but I was using SurfaceView properly as you >> mention Romain Guy but changing my code over does not work. The problem and >> code was posted here
>> On Monday, 1 October 2012 18:17:57 UTC+2, Romain Guy (Google) wrote:
>>> There is an overhead associated to invalidate() but unless your >>> hierarchy is extremely complicated it shouldn't be such an issue. But >>> you're right: SurfaceView can be used to avoid calling invalidate() >>> but don't override it's onDraw() method. You usually create a new >>> thread that renders onto the surface.
>>> On Mon, Oct 1, 2012 at 2:53 AM, Ajit Vasudevan <vasu...@gmail.com> >>> wrote: >>> > Hi Romain,
>>> > Thanks for your response.
>>> > I was experiencing a very interesting behavior. I started using a >>> custom >>> > view inside a framelayout, and performed all the primitive operations >>> and >>> > called invalidate() to let the system call onDraw. It was choking. I >>> even >>> > tried to invalidate a rect, but it was just not fast enough - the 2nd >>> view >>> > that was requesting the underlying view to redraw certain primitives >>> based >>> > on the actions on the 2nd view was not responsive. I then started >>> using the >>> > SurfaceView to see if there is any benefit for the same operation - >>> and >>> > voila - it worked like a charm. This is why is used SurfaceView as a >>> > substitute - there was an apparent performance benefit.
>>> > That said, I'm going to take another look at my hierarchy, and all >>> the >>> > custom views (there are quite a few), to make sure there are no other >>> leaks. >>> > Like you said, I would rather use a View instead of SurfaceView. >>> Thanks for >>> > your input though - it does answer the question that I can use a >>> canvas with >>> > TextureView if i follow the intended mode of use.
>>> > -Ajit
>>> > On Saturday, September 29, 2012 2:47:45 PM UTC-7, Romain Guy (Google) >>> wrote:
>>> >> Hi,
>>> >> If you were using SurfaceView's onDraw() method then you were not >>> >> getting any benefit. You have to use >>> >> lockCanvas()/unlockCanvasAndPost() and post on the underlying >>> Surface. >>> >> TextureView works in a similar way: you can call >>> >> lockCanvas()/unlockCanvasAndPost().
>>> >> However, it seems all you need is a View. It's easier to use and >>> since >>> >> you are not using SurfaceView properly anyway it will do the same >>> >> thing.
>>> >> On Thu, Sep 27, 2012 at 2:19 PM, Ajit Vasudevan <vasu...@gmail.com> >>> wrote: >>> >> > Hello,
>>> >> > I am currently working on an app that requires >>> computations/rendering >>> >> > based >>> >> > on a variety of user inputs. I have implemented the SurfaceView and >>> >> > things >>> >> > work as expected. >>> >> > But I started facing performance issues when I tried to put this >>> inside >>> >> > a >>> >> > horizontal scroll view. Obviously it is not intended to work this >>> way - >>> >> > but >>> >> > I tried anyway :) >>> >> > Based on what I have read - it appears like I have to move to >>> >> > TextureView. >>> >> > But i am unable to override the onDraw, and therefore cannot >>> perform the >>> >> > necessary drawing using the Canvas. This might be a trivial >>> question - >>> >> > but I >>> >> > wanted to know if we can use TextureView to draw primitives on the >>> >> > screen >>> >> > using a Canvas? The only examples I have seen thus far show the use >>> of >>> >> > video/camera/openGL rendering on the TextureView.
>>> >> > Any help on this would be great.
>>> >> > Thanks much >>> >> > -Ajit
>>> >> > -- >>> >> > You received this message because you are subscribed to the Google >>> >> > Groups "Android Developers" group. >>> >> > To post to this group, send email to android-d...@googlegroups.com >>> >> > To unsubscribe from this group, send email to >>> >> > android-developers+unsubscribe@googlegroups.com >>> >> > For more options, visit this group at >>> >> > http://groups.google.com/group/android-developers?hl=en
>>> > -- >>> > You received this message because you are subscribed to the Google >>> > Groups "Android Developers" group. >>> > To post to this group, send email to android-d...@googlegroups.com >>> > To unsubscribe from this group, send email to >>> > android-developers+unsubscribe@googlegroups.com >>> > For more options, visit this group at >>> > http://groups.google.com/group/android-developers?hl=en
