On Jul 5, 10:30 am, "Romain Guy" <[EMAIL PROTECTED]> wrote:
> 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.
Looking forward, thats not really going to be an issue. The bigger
issue will be capability.
> 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 a valid example - nobody would want to do that.
> > 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.
If you are only going to cater to the lowest common denominator, then
I think you have already lost the battle for market share.
> > 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:
My playing around indicates that the openGL and rasterized views dont
play well together, would you say this is true? You can overlay a
surfaceview with raster graphics, but you cant really mix and match.
Loading textures is also painful. Obtaining any kind of composited
window effect also sems very hard, if not impossible.
>
> > 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.)
this is a good start. nice to hear.
> --
> Romain Guywww.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
-~----------~----~----~----~------~----~------~--~---
