I am suspecting using the view cache system causes the view system to
allocate memory for the view.
Now lets say I can to capture 3 views, does that mean memory is
allocated for 3 views worth of caches if I don't destroy the cache?

Also I noticed through profiling that this code runs around 100ms
view.setDrawingCacheEnabled(true);
        view.setDrawingCacheQuality(View.DRAWING_CACHE_QUALITY_HIGH);
        view.setDrawingCacheBackgroundColor(Color.BLACK);
        Bitmap bitmap = view.getDrawingCache();
        Bitmap retVal = bitmap == null ? null :
bitmap.copy(bitmap.getConfig(), false);
        view.destroyDrawingCache();
        view.setDrawingCacheEnabled(false);
        return retVal;

while this runs at around 60ms
mCanvas.setBitmap(mBitmapCapture);
   view.draw(mCanvas);
   Bitmap retVal = mBitmapCapture;

I have to capture a few views and trying to speed them as quick as
possible and at the same time not use much memory. I guess the slight
speed difference is in enabling and destroying the view drawing cache?
What is the effect of not destroying it? Does that mean it will suffer
from my approach above that is double the workload on each frame as
well?

Going back to my approach my code is just as I pasted it, should I be
saving the canvas and restoring it in the dispatchDraw? Any help is
appreciated. Thanks.




On Jun 24, 9:47 am, Romain Guy <[email protected]> wrote:
> It's either because you don't properly save/restore the state of your
> offline Canvas or maybe because of the bitmap config (although it
> should work just fine in 565.)
>
> What I don't understand however is why you refuse to use the drawing
> cache API that already exists for this purpose? Using this API will
> not necessarily force another redraw of the view. With the drawing
> cache, the cache is automatically redrawn whenever the view changes.
> Your approach however doubles the workload on *every* frame.
>
>
>
>
>
>
>
>
>
> On Thu, Jun 23, 2011 at 4:23 PM, rukiman <[email protected]> wrote:
> > I am trying to understand which this code which works perfectly for
> > capturing almost any view except if there is a ScrollView in the
> > framelayout, in this case there is a slight issue with the top and
> > bottom areas where scrollview fades its contents. There is some
> > corruption occurring.
>
> > public class FrameLayoutWithOfflineBitmap extends FrameLayout {
>
> >        private Bitmap mOfflineBitmap;
> >        private Canvas mOfflineCanvas;
>
> >        public FrameLayoutWithOfflineBitmap(Context context) {
> >                super(context);
> >        }
>
> >        @Override
> >        public void onSizeChanged(int w, int h, int oldw, int oldh) {
> >                // just in case we already had the bitmap allocated before
> >                if(mOfflineBitmap != null) {
> >                        mOfflineBitmap.recycle();
> >                }
> >                mOfflineBitmap = Bitmap.createBitmap(w, h, 
> > Bitmap.Config.RGB_565);
> >                mOfflineCanvas = new Canvas();
> >                mOfflineCanvas.setBitmap(mOfflineBitmap);
> >        }
>
> >        @Override
> >        public void dispatchDraw(Canvas canvas) {
> >                // draw to our offline bitmap
> >                super.dispatchDraw(mOfflineCanvas);
> >                // now draw our offline bitmap to the system canvas
> >                canvas.drawBitmap(mOfflineBitmap, 0, 0, null);
> >        }
>
> >        public Bitmap getScreenSnapshot() {
> >                return mOfflineBitmap;
> >        }
> > }
>
> > I understand there are other ways to capture the view such as using
> > the View's drawing cache, but I am not interested in this method. Can
> > someone explain to me what is going on here and if there is way to
> > address this issue? Basically I am trying to get access to a snapshot
> > of a view as quick as possible. My idea is that the view is already
> > drawn onto the screen, we should be able to get access to this without
> > having to force another redundant redraw of the view.
>
> > I am also very keen to understand the flaw with the above code in
> > terms of the scrollview. Thanks.
>
> > --
> > You received this message because you are subscribed to the Google
> > Groups "Android Developers" group.
> > To post to this group, send email to [email protected]
> > 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
>
> --
> Romain Guy
> 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 [email protected]
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

Reply via email to