Because you have to translate the Canvas by -scrollView.getScrollY() first.

On Sun, Jun 26, 2011 at 9:53 PM, rukiman <ruksh...@optushome.com.au> wrote:
> Do you know why calling view.draw() on a scrollview draws the screen
> disregarding the current scrollY and assumes the scrollview is at the
> beginning always?
>
> On Jun 24, 10:14 am, Romain Guy <romain...@android.com> wrote:
>> The drawing cache is per view, so if you need to capture several views
>> (sibling, and not a subtree like you are doing in your example) if
>> would be better to allocate a single bitmap. This works of course only
>> if all the views have the same size.
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> On Thu, Jun 23, 2011 at 5:06 PM,rukiman<ruksh...@optushome.com.au> wrote:
>> > 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 <romain...@android.com> 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<ruksh...@optushome.com.au> 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 android-developers@googlegroups.com
>> >> > To unsubscribe from this group, send email to
>> >> > android-developers+unsubscr...@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
>>
>> >> 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
>> > android-developers+unsubscr...@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
>>
>> 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
> android-developers+unsubscr...@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

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
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en

Reply via email to