A few points: -I've never seen a visual designer who had any problem with using bitmaps as their final output.
-I've never seen an SVG implementation that could output bitmaps that looked as good and that rendered as fast as plain bitmaps for images with pixel-sized details. -Scalable UIs don't require scalable graphics, and scalable graphics don't require vector graphics (MacOS, in fact, uses stretchable bitmaps and mipmaps when relevant). -The blog you quoted says that the decision of "deciding whether that line is 1 pixel or 2 pixels thick" is a programmer's decision, but that's not, it's a designer's decision. -In the Android architecture, you're very isolated from such concerns when programming - you are probably simply loading layout resources, which (through views that could implement some scaling logic) reference drawable resources. That's just enough levels of abstraction that if you need to care about the details of the graphics rendering you're probably doing something wrong. -Finally, since the Android platform will be open-source, nothing will prevent you or anybody else from modifying Android to use another graphics system. And if you're willing to contribute it back and your contribution is accepted, it'll end up in a future version of Android. JBQ (Android Engineer) On Jul 4, 4:22 am, stefoid <[EMAIL PROTECTED]> wrote: > etc... > > this quote from this blog says it clearly. the lack of hardware > acceleration for androids 2D graphics API, oand for any resolution > independent way of defining your UI is a showstopper. > > http://unqualified-reservations.blogspot.com/2007/11/five-problems-wi... > > "Third, Android's graphics framework uses pixel coordinates and > immediate-mode 2D drawing. > > Now this is just a mistake. I was looking at the doc and I could have > sworn that someone had mischievously linked me to the Xlib manpages. > WTF, guys? Is there a timewarp in Mountain View I don't know about? I > know you're on the old SGI campus, but really... > > The idea that, in 2007, anyone is writing 2D UIs with pixel drawing > functions just burns me up. The right way to draw a UI is to construct > a vector data structure, a la SVG or whatever, that represents the > visual state of the screen in resolution-independent coordinates, and > then just render the fscker. No, you don't have to actually construct > an SVG text file. You even have a GL library in there! You can just > treat 2D as a special case of 3D! People! > > This is not just an esoteric developer issue. It has real usability > ramifications. > > I don't know anything about the iPhone's software stack, but I'm > pretty sure it uses Quartz, in which all coordinates are device- > independent. But I didn't even need to know this. The whole UI just > screams "vector." As soon as I saw the demos, my first thought was > "now no one will ever write another GUI which uses raster graphics." > Little did I know that down in Mountain View, a crack team of hotshot > Googlers was busy recreating the Athena toolkit. > > With a lot of work, with good layout and compositing and so forth, it > is possible to make a raster UI look pretty good. The Android UIs look > pretty good. But they don't look anywhere near as slick as the iPhone. > When you don't isolate device coordinates completely from the > programmer, they leak everywhere. You are constantly deciding whether > that line is 1 pixel or 2 pixels thick. And your designers curse you > all day long. > > You do need a couple of things to build a pure vector UI. You need a > high-resolution screen, a fast CPU, and hopefully some kind of GPU. > But - as the iPhone proves - all of these are available in products > shipping today. There is simply no excuse for creating a new platform > in which applications are not isolated from device-dependent screen > coordinates. > " --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
