ImageView works remarkably well. In our case, we have users input updating
scroll and zoom values, a custom animator [potentially] updating scroll and
zoom values, and network code updating the image data. We found better
performance using SurfaceView with a pattern like this (psudo-code, revised
to meet the needs of the poster):
// core of Drawing thread
while( running ) {
wait for signal;
if( running )
draw
}
// drawing code
// Width = image width
// Height = image height
// W = screen width
// H = screen height
// X = scrolled X position (in the range [0, Width-W])
// Y = scrolled Y position (in the range [0, Height - H])
Create SRC Rectangle from (X, Y, X+W, Y+H)
Create DST Rectangle from (0, 0, W, H)
Draw original image into canvas (onto surfaceview) using SRC and DST rects
// This is the BLT
// Touch event code
Manage relative motion and change X and Y appropriately
Validate that X and Y are within valid ranges
Notify the object that the drawing thread is waiting on (releasing one
background draw)
This is pretty standard game-like drawing logic. Update the model on one
thread, signal a draw thread to update the UI.
If you are doing something much more draw-intensive and need extra CPU
cycles, sleep the UI thread after each touch for some small period (10 ms or
so) and be sure to handle history data in the MotionEvents.
Scott
SoftwareForMe.com
On Thu, Nov 12, 2009 at 2:58 PM, Lee Laborczfalvi <labor...@gmail.com>wrote:
> To render to a SurfaceView you need to get the SurfaceHolder, lock it and
> then draw to the Canvas and finally unlock it.
>
> Have you considered an ImageView and just calling invalidate and doing your
> drawing in onDraw?
>
> Lee
>
> On Fri, Nov 13, 2009 at 9:32 AM, Genc <gmt...@gmail.com> wrote:
>
>> Hi Scott.
>>
>> Thanks for great tips.
>>
>> I've changed my code and not using Gestures any more, just onTouch
>> method and handling ACTION_MOVE motion.
>>
>> It's good up to this point.
>>
>> However, can you give a little sample code about blting a bitmap to
>> surface? How can I do this?
>>
>> Thanks
>>
>> On Nov 12, 8:18 pm, "SoftwareForMe.com SoftwareForMe.com"
>> <softwareforme....@gmail.com> wrote:
>> > * Skip the gesture detector, just handle the touch events yourself
>> > * Do not create a new bitmap. Load it once and blt from it to the
>> surface
>> > * Background thread should wait on some object to be notified by UI
>> thread
>> > when new x/y scroll is available, then draw
>> >
>> > We use this approach in PhoneMyPC and have very responsive scrolling of
>> > quite large images.
>> >
>> > Scott
>> > SoftwareForMe.com
>> >
>> >
>> >
>> > On Thu, Nov 12, 2009 at 7:58 AM, Genc <gmt...@gmail.com> wrote:
>> > > Hi all,
>> >
>> > > For a project, I'm displaying an image with sizes 800 x 600 and I've
>> > > implemented my custom scrolling (horizontal and vertical) - which is
>> > > works fine. However, my problem is that it's not fast enough. If you
>> > > continuously move your finger on screen for instance, scrolling is not
>> > > responding fast enough. There is a lag and you need to wait (say
>> > > 400-500ms) for new scrolled image to be loaded.
>> >
>> > > Now below I described how I implemented scrolling and my question is
>> > > that
>> >
>> > > - How can I make it faster, if possible
>> > > - Is there any other better way to implement this.
>> >
>> > > Thanks in advance!!
>> >
>> > > --------------------------------------------------------
>> >
>> > > My custom scrolling solution:
>> >
>> > > * I have a Main activity, SurfaceView and a thread
>> > > * In main activity, I'm using GestureDetector and override onScroll
>> > > method.
>> > > * In onScroll method of activity, I'm passing values to SurfaceView's
>> > > "handleScrolling" method.
>> > > * In "handleScrolling" method, I'm calculating proper values and using
>> > > "newImage = Bitmap.createBitmap(myImage, starX, stopY, SCREEN_WIDTH,
>> > > SCREEN_HEIGHT)"; to create a new, "scrolled" image.
>> >
>> > > * Then in thread loop, I'm drawing this "newImage" to canvas.
>> >
>> > > Hope this much info helps.
>> >
>> > > --
>> > > 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<android-developers%2bunsubscr...@googlegroups.com>
>> <android-developers%2bunsubscr...@googlegroups.com<android-developers%252bunsubscr...@googlegroups.com>
>> >
>> > > For more options, visit this group at
>> > >http://groups.google.com/group/android-developers?hl=en
>> >
>> > --
>> > Warm regards,
>> > The PhoneMyPC Team
>>
>> --
>> 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<android-developers%2bunsubscr...@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+unsubscr...@googlegroups.com<android-developers%2bunsubscr...@googlegroups.com>
> For more options, visit this group at
> http://groups.google.com/group/android-developers?hl=en
>
--
Warm regards,
The PhoneMyPC Team
--
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
