Vector graphics are not magical. First of all, a vector graphics engine require expensive rendering if you want to be able to create results that have as much details and effects as traditional raster graphics. They also cause no end of trouble when you try to render them at small sizes. You could create a beautiful icon in SVG, that looks amazing at 256x256, but will look really bad at 32x32. In this case, you'd be better off mixing vectors (for large sizes) and bitmaps.
> Not to mention there are effects that the openGL type hardware gives > you for very little programming effort that would take a lot of time and > performance to > duplicate. The contrary is also true. There are many effects that OpenGL doesn't let you do easily. For instance, many things you can do today with Android's 2D APIs cannot be done easily in OpenGL ES 1.0 and 1.1. Circular gradients are a very good example. OpenGL ES 2.0 lets you do a lot more but the chips are very new and it will take some time before they are ubiquitous. Also you cannot count on all phones to have hardware support for accelerating graphics nor can you count on all phones having good graphics drivers. > I think the point is that its a decision that doesnt need to be made > at all if you use scalable graphics. Actually you have to. Because you don't have control over the rendering, scaling vectors can produce results that are wrong by a few pixels at certain sizes. You cannot guarantee the result. > is there a reason why the android graphics API cant have the option of > sitting on top of a vector engine as well? > give people the choice depending on the hardware they are aiming at. Android provides a 2D raster API, which you need anyway to render vector graphics. It is perfectly possible to add an API on top of the current one. Note that Android already provides some support for pixel independence and vector graphics. All Views can be sized using logical units (dip, for device independent pixel, and sp, for scaled point) and you can define vector graphics in XML. For instance, Android's circular progress bar is defined entirely this way: <layer-list xmlns:android="http://schemas.android.com/apk/res/android";> <item android:drawable="@android:drawable/progress_circular_background" /> <item> <shape android:shape="ring" android:innerRadiusRatio="3.4" android:thicknessRatio="6.0"> <gradient android:useLevel="true" android:type="sweep" android:startColor="#ff000000" android:endColor="#ffffffff" /> </shape> </item> </layer-list> > nothing except time and effort thats not mine to assign. I think this > will be an important issue when the big phone companies bring out > their next phones to compete with the iPhone and android starts to > look pretty shabby by comparison as early as the next year or two. > better start thinking about it now rather than be reactive. Again, vector graphics won't do anything magical for you. The current approach, using 9-patches (stretchable bitmaps) and logical units, is a good match for current and soon-to-come hardware: it's flexible and fast. Note that the next public Android SDK will provide a way to enable hardware acceleration (through OpenGL) for the standard Views and 2D APIs. But again, this won't do any good on devices with no good hardware support and good drivers. Hardware acceleration has also other drawbacks compared to a software rendering (for instance, you cannot easily redraw just a small portion of the screen, you have to refresh everything.) -- Romain Guy www.curious-creature.org --~--~---------~--~----~------------~-------~--~----~ 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] Announcing the new M5 SDK! http://android-developers.blogspot.com/2008/02/android-sdk-m5-rc14-now-available.html For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -~----------~----~----~----~------~----~------~--~---
