> -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.
Dont know about that, seems like a designer issue to me.
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.
> -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).
scalable in what way? lets say I wanted to shrink my dialog on the
screen to make way for some new item? or zoom in on a spot in the
dialog
to see fine detail obscured by a full-page view? that type of
scalable.
> -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.
I think the point is that its a decision that doesnt need to be made
at all if you use scalable graphics.
> -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.
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.
> -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.
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.
> 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.
> > "- Hide quoted text -
>
> - Show quoted text -
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
