flick scrolling

by bob » Fri, 20 May 2011 08:36:07 GMT

Sponsored Links
 Is there an easy way to do that scrolling where someone moves their
finger really fast across the screen and the scrolling continues a bit
after their finger has lifted?


Re: flick scrolling

by TreKing » Fri, 20 May 2011 08:43:06 GMT


Yup - real easy - just put your finger down on a scrollable item on the
screen and flick it really fast. It will do exactly what you describe.

TreKing < http://sites.google.com/site/rezmobileapps/treking> ; - Chicago
transit tracking app for Android-powered devices


Sponsored Links

Other Threads

1. Do VBOs really improve performance? Really?

That's is a good point but it's still likely some kind of gain a the 
driver can preprocess the vertices into a format it prefers.


Do VBOs do anything on a device with unified memory? There is no separate graphics memory on many of these devices, right?
Navigateur, Performance is highly device-dependent. If you're not seeing any performance differences, it would be helpful if you listed on which device, what your FPS is with/without VBOs, etc.. It sounds like you're doing it right. I doubt it matters how you partition the vertex attributes. You can do what you do or do what I do which is have 3 separate VBOs for them. I would expect no difference there. If you're not getting a performance improvement then that's not a bottleneck for your app/game, but it's still lightening the load on the bus so is a good thing overall. Most games are fill-bound, not vert-bound.
What is your approximate experimental fps improvement using exactly the same content with and without VBOs? I'm testing with 3000 static verts (GL_STATIC_DRAW) and I'm getting exactly the same frame rate with and without VBOs, only the set-up time is longer with VBOs. What are your results with and without? If you're sure there's an improvement, then what might I be doing wrong with my VBOs? (I'm using 2 VBOs, one for the indices and the other for verts, normals and texturecoords) And what's your way of doing it?
The question "are VBOs faster" is a very subjective one.
I can answer the question "are VBOs faster for large amounts of static geometry" and the answer in my experience has been "yes, very much so, especially on first-gen devices."
For quads and such? No. In fact, it could actually be slower depending on the chip and implementation.
VBOs are designed to reduce bus bandwidth usage for static geometry. If you're not pushing too much across that bus (as in the case of quads or very few, very low poly objects), they won't do much. If, on the other hand, you're actually running static scenes that are moving 5k polys per draw eg (7.5k verts, 7.5k normals, 15k indices, 7.5k UVs) = 270Kb, you will most likely see some sort of improvement, especially on chips like the qualcomms as they have fairly slow transfers. Just think, 270Kb @30fps = 8.1Mb of memory copying per second you're saving using VBOs.
If you're rendering scenes that have REALLY large amounts of geometry (for mobile), such as 50k or 100k polys, you'll find that you'll be totally vert-bound on the first gen devices, so there's kind of that limit there as to how effective VBOs can be. The spots where they REALLY shine, like really high poly counts, can't ever be used on the first-gen phones because they are incapable of processing that many vertices with high efficiency anyway. High end devices running big scenes like that will really benefit from them because it's a whole lot of memory transfer savings. Anyone doing things like that will want to be using configurable LoD to support the first-gens while keeping things high quality on newer chips.
I would be interested in a simple test that increases poly count frame by frame and graphs the FPS up from 0 to 100k polys. Running one pass textured and the other just colored would be a good way to discriminate between becoming fill-bound and memory or vert-bound. Seeing this data on an MSM7200, Cortex/PVR (Droid) and a snapdragon would be very useful for determining optimization targets.
No I'm not even using draw_texture. I'm comparing using VBOs to just ordinary Buffers for the vertices (and no draw_texture). My test is not near the max frame rate for my device.
Well, if you look at the talk google gave the developer gave a short note about it:http://code.google.com/intl/es-ES/events/io/2010/sessions/writing-rea... If memory serves me correct, you won't gain much of a speed gain from using VBOs as opposed to say draw_texture. This is because the FPS is capped at 30FPS for some devices, however I can't recall the details.
I've been trying VBOs (3D) and I've seen no improvement at all on my Motorola Dext over not using VBOs.
I've tried all kinds of configurations, interleaved arrays, bytebuffers instead of floatbuffers, both direct and indirect.
My question is, has anybody got any measured improvement in frames per second by using VBOs instead of exactly the same content without VBOs?
If and only if so, what were your fps results? And can you therefore show me the "proper" way of doing VBOs instead of not? Has anybody else got exactly the same fps with and without VBOs?

2. SurfaceComposerClient: using an invalid surface id

I'm making a game, using GLSurfaceView, and I keep getting this error
message when returning to my game after pressing Home:

"using an invalid surface id=[some integer], identity=[some integer],
should be [some integer]"

Then it takes a few seconds before the GLSurfaceView is drawn again,
even if requestRender() is called.

I have not encountered much info on the net as to what that error
message means, or how to avoid it. Is there any documentation I could
look into?



3. Simple Cursor Adapter - List View

4. Null canvas being passed to onDraw(Canvas canvas)

5. Diffrece Between Android Kernel and Linux Kernel

6. draw hands on canvas

7. Compose email japri