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
