I want to implement a news ticker in my application, with vertical and horizontal scrolling, as well as some alpha animations.
I need the animation to be unaffected by the rest of the application (GPU/hardware accelerated). Especially since the application will be run on a Google TV box, and the user is expected to be using D-Pad navigation which can cause animation to become choppy.
These appear to be my options (I need to support Honeycomb and above):
Use the Android Animation classes
Will the performance of this approach ever match using OpenGL?
Is hardware acceleration possible, and reliable?
Easiest to work with.
OpenGL ES 2
There appears to be a limit to the texture size of 2048. If I have a headline longer than that
RenderScript
The documentation is sparse here.
In your opinion, what is the best solution? What other solutions are there?
One pattern that's common is to enable hardware acceleration, animate, then disable it. However, on the Intel based GoogleTV boxes there is a problem with text when you turn on Hardware Acceleration. I haven't tried it on an ARM based Google TV yet.
I am by no means an OpenGL ES expert, but I am a huge fan and have seen some wonderful things done using it for Google TV. That said, I think your understanding of OpenGL ES Textures is incorrect. The size of the texture should have little bearing on the length of a headline. I currently have an intern working on a bunch of OpenGL ES examples that we hope to publish by the end of August.
There is excellent sample code for working with RenderScript, even if the documentation is sparse. However some developers haven't been able to integrate RenderScript w/ d-pad navigation.
My suggestion is to try your worst case senario using OpenGL ES as a very short program and see how it works. It's likely to be the best solution.
I can imagine why your seeing choppiness on some GoogleTV animations, StateLists firing when D-Pading, but it's not an insolvable issue.
Related
I was using OpengGL (Gles2WatchFaceService.engine) for my Wear-OS watch-face projects and it was working great for years. Recently however, this engine got deprecated and therefore, before I recode all my graphics, I am reevaluating if OpenGL is needed at all.
My question to any experienced (watch face) developers here is: When should I use OpenGL for the graphics of a watch face? Only for 3D animation? What about an analog watch face with hands that should move smoothly (with the animation frame rate switching between 5 and 40 fps)? (I am also using some color blending with alpha channel, not sure if I can do that without OpenGL.)
It comes basically down to these considerations:
OpenGL for pure 2D animation could result in smoother animation at a lower CPU load. But, is this always true? Or can I get easily 40 fps for animating up to 9 graphical elements without OpenGL?
Am I getting the advantages of OpenGL (if there are any) at a cost of a more complicated code and more compatibility problems in the future (due to SW and HW updates)?
If OpenGL is the way to go, perhaps someone can point me to a good and recent code example (preferably java), because I can't find any.
Any help/comments appreciated!
Is actually in the end everything rendered via OpenGL in Android. I have already checked out this video https://youtu.be/zdQRIYOST64 and the relevant documents. And it seems that not all is rendered via OpenGL or maybe Vulkan nowadays. But when it is not rendered via this, how is it rendered, via some internal stuff inside the SurfaceFlinger?
Can someone show up the way through the code from the application level to the very last point before the hardware?
I have asked #Romain Guy on twitter to answer this question and this is his answer
https://twitter.com/romainguy/status/1272314819333337090
Apps are rendered pretty much entirely with OpenGL yes. SurfaceFlinger
avoids using the GPU whenever possible and uses dedicated compositing
hardware instead (hardware composer). But sometimes it falls back to
GL.
I was wondering what will be the best solution or method to implement motion graphics animations in an android application .
Check out this website.
https://uxplanet.org/bringing-mobile-apps-to-life-through-motion-9472d259b58e
I want to implement same type of animations.
How can I do that?
What is the best industry standard to do this?
Should I be using After Effects animations and render them into android application or can I achieve this using Open GLES ? Which will be the fast and efficient way ?
Thanks
Design is no doubt an integral part of any app. Hence, design must also be taken in consideration along with the functionalities of the app. Motion Graphics in Android can be implemented in many ways. Android itself provides a rich set of powerful APIs to implement animations to various UI elements. For animations, Android has the 'PropertyAnimation', 'ViewAnimation' and the 'DrawableAnimation'. The Property Animation is a powerful system which can be used to achieve complex animations for both View and nonView objects. The view and drawable animations are a bit simpler systems to achieve simpler animations.
For drawing graphics in Android, you can use the Android Canvas or the OpenGL ES. OpenGL is an extremely powerful tool for manipulating and displaying high-end animated 3D graphics and can use hardware accelerated GPU. Please look into the Android docs for exact codes for implementation.
Now considering After Effects animations, they are really neat and perfectly fit the design aspects of the app. However the animations rendered by After Effects tend to be large in size and end up making the final app big in size. Personally, I have used AE rendered animations for my splashscreen and only a few other animations. Finally, it depends on your coding abilities since implementing complex animations using Android systems would be hard, whereas AE animations would make the app size large.
Hope this answers your question.
I am a fairly "newb" Android developer, and I would like one of my first projects to be a live wallpaper, however I am conflicted on whether I should be focusing on Canvas or OpenGL for it. Being new to this I know I should master Canvas first since it is easier to use, but I prefer to learn from real world projects that I have an interest in, even if it's a little backwards at times.
I have used both before in very basic ways, and I understand the general concepts to them, but I am not sure how they transfer over to the realm of live wallpapers. I figure that the full blown speed of OpenGL isn't required on a live wallpaper, since running it at max FPS would just run down the battery more than it necessary, but at the same time I am worried that using Canvas would cause lags and stutters when doing things like changing home screens.
I have been leaning towards using OpenGL ES 2.0, both to keep performance optimal and because my initial ideas for the wallpaper involve a lot of layering that I am not sure Canvas is capable of, but I'd like a more experienced developers opinion on whether or not all of the extra work involved in using OpenGL (especially in relation to live wallpapers, from what I've read) is worth it.
If you can get away with just drawing to a canvas (e.g. cube example in SDK), that's much less work. Because of the simplicity of the animation (no bitmaps), the cube is able to achieve a high frame rate without difficulty.
If you want to use OpenGL, you will need to use a supplemental package, such as GLWallpaperService, AndEngine, or RenderScript.
http://www.rbgrn.net/content/354-glsurfaceview-adapted-3d-live-wallpapers
http://www.andengine.org/forums/tutorials/live-wallpaper-template-t258.html
Browse the Android source code to see how the stock wallpapers (e.g. Grass, Galaxy) are implemented using RenderScript. This link may work, but no guarantees: http://grepcode.com/file/repository.grepcode.com/java/ext/com.google.android/android-apps/4.1.1_r1/com/android/wallpaper/ (then scroll down to the wallpapers)
Moonblink has discontinued his project, but if you're really keen, you can try researching his work (Substrate) starting here: http://code.google.com/p/moonblink/source/browse/wiki/Setup.wiki
I ended up using OpenGL as halfway through the project, canvas drawing proved to be too slow for what I was trying to achieve. Using OpenGL caused a massive performance boost. Unfortunately I had to refactor my code, so I would reccomend using OpenGL from the start. Dirty rendering is supported by OpenGL as well as the wallpaperservice's structure doesn't rely on the way you render things so you would still be able to create a wallpaper that doesn't drain the battery. Actually a well programmed wallpaper doesn't render when it's hidden. As the wallpapers shipped with android don't follow that pattern, live wallpapers now have the bad name of being battery suckers. Really a shame..
I want to create a simulation game and a main component of this simulation will be a 2D map (topographical/navigation map), which shall have different layers (objects are moving on the map, using of labels, you get it)
The question for me is now, shall I use OpenGL to accomplish this or is that not necessary? I have no special requirements apart of that the scrolling and zooming shall be smooth. The target platform are only Android tablets (so Android OS 3.0+).
Edit: To precise my question:
platform independence is not important for me
I'd like to go with the easiest way concerning implementation efforts
If and only if you're really targeting Honeycomb specifically, then don't bother with OpenGL... and I say that as a reasonably experienced OpenGL programmer who's done some cool things with it on Android.
My reasoning is that, starting with Honeycomb, the normal Canvas-based APIs are hardware-accelerated too. Typically the only real reason for using OpenGL was greatly increaased performance, but that is no longer the case.
Or so the theory goes... I've yet to see actual Honeycomb hardware and run comparative tests. What I do know is that the Honeycomb emulator shows triangular tearing everywhere, strongly suggesting the whole desktop is now going through the GL pipeline.
If you have solid experience with OpenGL go with it. If not try some performance tests before you really decide if you invest time to learn it or if you use the good old simple 2D canvas drawing...
I'm not an expert on OpenGL + android (or any other mobile devices), but I think you will get better results (more FPSs, better drawing and animation options, etc) using OpenGL.
If you're used to non-OpenGL android development and are new to OpenGL it would be easier develop the game without using OpenGL. But before you choose this option, be aware that it should be a better option to use OpenGL if you aim to achieve beautiful/good performance graphics!
In short, if you master "regular" android development and prefer to build something good enough in a short time, stay "regular". Otherwise, I advice you to go for OpenGL.