> Looking forward, thats not really going to be an issue. The bigger > issue will be capability.
Please remember that we're talking about phones, not desktops. Expensive rendering is still a problem. > not a valid example - nobody would want to do that. If my phone had a 600x800 screen I would want that. > If you are only going to cater to the lowest common denominator, then > I think you have already lost the battle for market share. If you are going to ignore the LCD, then you have lost market share. Remember that Android was created to run on EVERY phone. When we create an application, it has to be prepared to run on all processor speeds, all screen sizes, etc. Say OHA takes your plan and ignores the LCD, at that point it won't just lost the battle for market share, it won't even show up. On Jul 4, 9:06 pm, stefoid <[EMAIL PROTECTED]> wrote: > 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 -~----------~----~----~----~------~----~------~--~---
