I would like to be able to incorporate hand gestures to several hundred to thousand dynamically generated polygons so that I can pinch to zoom and drag all of them (not individually) simultaneously in Android. What is the best way to achieve that? Obviously, if there is a library that would be great, but if not could/should I scale/drag the canvas or the view object? An alternative is to convert the vector to a bitmap image, but I think for my purposes it would be very computationally intensive to do all that processing.
Related
This is a big issue for me I'm trying to figure out for a long time already.
I'm working on an application that should include a 2D vector indoor map in it.
The map will be drawn out from an .svg file that will specify all the data of the lines, curved lines (path) and rectangles that should be drawn.
My main requirement from the map are
Support touch events to detect where exactly the finger is touching.
Great image quality especially when considering the drawings of curved and diagonal lines (anti-aliasing)
Optional but very nice to have - Built in ability to zoom, pan and rotate.
So far I tried AndEngine and Android's canvas.
With AndEngine I had troubles with implementing anti-aliasing for rendering smooth diagonal lines or drawing curved lines, and as far as I understand, this is not an easy thing to implement in AndEngine.
Though I have to mention that AndEngine's ability to zoom in and pan with the camera instead of modifying the objects on the screen was really nice to have.
I also had some little experience with the built in Android's Canvas, mainly with viewing simple bitmaps, but I'm not sure if it supports all of these things, and especially if it would provide smooth results.
Last but no least, there's the option of just plain OpenGLES 1 or 2, that as far as I understand, with enough work should be able to support all the features I require. However it seems like something that would be hard to implement. And I've never programmed in OpenGL or anything like it, but I'm willing very much to learn.
To sum it all up, I need a platform that would provide me with the ability to do the 3 things I mentioned before, but also very important - To allow me to implement this feature as fast as possible.
Any kind of answer or suggestion would be very much welcomed as I'm very eager to solve this problem!
Thanks!
I'm relatively new to Android development, and I'm currently developing an app that requires a pinch-zoomable and pannable image that will have other images overlaid on top of it, similar to a MapView but without using the Google Maps API.
I've done a bit of looking and found that I may be able to accomplish the overlay portion by doing the method in this question: Draw images on top of each other in android
However, I don't know if that would make the ability of doing a pinch-zoom and/or panning a large image feasible. Would it be worth it to create a GLSurfaceView and just implementing the needed functionality, or is that overkill because I'd be reinventing the wheel?
For what it's worth, the large map image itself will be fetched from a server (but if needed it can be split into smaller square regions), and the icon that will be overlaid at various positions on the map will be embedded in the app itself.
Sony Ericsson made an excellent PinchZoomable ImageView class. I modified it for my needs. I merged their pinch zoom and single-point touch zoom (for phones that didn't have multitouch) http://code.google.com/p/motivatormaker-android/source/browse/MakeMotivator/src/com/sonyericsson/zoom/ImageZoomView.java
Their tutorial is here: http://developer.sonymobile.com/2011/04/12/how-to-take-advantage-of-the-pinch-to-zoom-feature-in-your-xperia-10-apps-part-2/
I got pretty good performance out of using these classes without needing to use OpenGL.
In my view I have a simple ARGB drawable that takes about 2ms to draw but I can draw the same file as a bitmap in under 0.5ms (just some quick code, I can't really consider it an option). What are the best ways to optimize the drawing speed of a drawable?
It will depend on the number of drawables and how many times each gets drawn. For a small number, use canvas (an exact number will also depend on the device) I would suggest using Canvas as it's a nice higher level approach to drawing.
If you want to crank out a lot of images (think hundreds), I would suggest creating a GLSurfaceView and using openGL to render your images using VBOs tailored to your app. I would also recommend using a texture sheet if you go down this route since you'll get a huge increase in performance at the cost of code complexity.
But this will also depend on that type of app. My background is in game development so I use openGL exclusively for better performance. for a simple app (something along the lines of androidify) Canvas should be fine. If you want a simple tutorial for openGL, I suggest visiting Bergman's series of posts on the topic (google should give you a link for that). It is a nice intro to openGL.
I am building aprogram that needs to do drag/drop operations of images. Now on a Canvas it is quite easy, and I might chose this. However, I am also interested in using GLSurface View?? Now what I am seeing in examples is either a drag/drop tutorial on Canvas or drawing on GLSurface view. I am wondering if handling touch events is more complicated with GLSurface view? Is it possible to handle touch events with GLSurfaceView. Also why would one chose GLSurface view for rendering images vs. a Canvas? How does one chose between Canvas vs. GLSurfaceView?
It's really just a choice between two APIs.
Canvas:
knows about common Android framework classes like Bitmap
many convenient functions
can draw into bitmaps for saving to the SDCard
GLSurfaceView:
good for using the tried-and-true OpenGL API
designed for redrawing rapidly at a certain framerate
3D drawing
These are just a few aspects of the debate. I don't think either of them has the upper hand on event processing. I'd say that it makes more sense to use Canvas if you are working primarily with the Android SDK, whereas GLSurfaceView is an especially good option for apps using the OpenGL APIs via the NDK.
i have an idea for an Android game which is a little different from the typical game that usually moves sprites(bitmaps) around the screen. Id want to plot lots of little pixels to create my visuals.
PROS
no bitmaps required
pixel plotting of stuff like "fire" can react to wind.
no need to scale bitmaps, works w/ any screen res (lets pretend device can handle more drawing because its got a bigger screen).
CONS
slower to plot pixels than blit bitmaps
need lot of animation frames.
WISHES
id like to update my game in real time, more is better 30fps is good but not essential, 15fps is enough.
PERFORMANCE Q...
Is the typical Android device fast enough to plot say half a screenful of pixels w/ a default background ?
if full screen is not practical what window size should be able to handle such refreshes
You can achieve it in native code using C/C++.
You would create offscreen bitmap, get its memory address, draw raw RGB pixels to it, then blit entire offscreen bitmap to screen in View.onDraw method. You can get nice framerates in fullscreen.
Btw, Android also manipulates pixels in low level by native code (using Skia library). Java classes like Canvas, Bitmap etc just jump to native code to get the work done.
Using Android's Canvas in Java to paint pixels would be unrealistically slow.