Excellent explanation/arguments Dianne. 5 stars from me.
On Jul 8, 4:00 am, hackbod <[EMAIL PROTECTED]> wrote: > On Jul 8, 12:04 am, stefoid <[EMAIL PROTECTED]> wrote: > > > 'phones'? hmmm. ok, lets use the term 'phone'. When did 'phone' > > hardware stop improving? > > "640K should be enough for anyone..." > > 6 years ago at a previous company the reference hardware we were > developing a phone platform for was a 200MHz ARM with 32-64MB of RAM. > > Today the reference hardware for the Android platform is a 200-400MHz > ARM with 64-128MB of RAM. And that target is still on the higher end > of phone hardware. > > The phone market is different than the PC market. That's just a fact > of life. There are many other factors that come into play in hardware > design, which are often more important than raw performance: price, > size, battery life, etc. > > That said, the "640K should be enough for anyone" line is pretty > extreme hyperbole, as is most of this drama over scalable graphics. > Not having scalable graphics everywhere is not going to kill the > platform. In fact, the original article you quoted was really over- > blown: > > - Comparing Android to X-Windows and the Athena toolkit is > ridiculous. The Android compositing engine is actually much more like > MacOS X than X-Windows, supporting full 3d hardware acceleration of > window compositing and transformation. The 2d rendering engine is a > path-based with full anti-aliasing and alpha blending support, far > beyond what X-Windows of that time supported. > > - The comment about the iPhone UI screaming vectors is questionable. > I don't know that much about the iPhone architecture, but to me it > screams 3d hardware acceleration being used to perform compositing and > transformation of bitmap textures, which is in fact how OSX has always > done its fancy animation and other UI tricks. There is a good reason > for this: pretty much any graphics acceleration hardware you find > these days is going to be really, really good at compositing and > transforming bitmap textures, and really not so good at the 2d path- > based rendering used for scalable graphics. > > - The quality of the iPhone UI vs. Android has nothing, zero, nada to > do with scalable graphics. All of the iPhone software is running on a > single device with a single density, so scalable graphics gain you > very little. They are helpful for things like web browsers were you > want to zoom in and out of the page, and oh hey both platforms are > using WebKit and the HTML DOM as a scalable representation on top of a > path-based 2d engine. But for animations using scaling and other > transformations, the best way to get those to run smoothly is by doing > them on bitmaps. One of the things that makes the iPhone feel slick > is that a lot of work was done to have those animations run at 60fps, > and that means everything going on there is the 3d hardware performing > rendering of bitmap textures. > > - The Android platform does incorporate screen density information at > the view layout level, where you can specify coordinates in a variety > of units (raw pixels, real inches or points on the screen, abstract > rounded "density pixel" units, or user-controlled "font scaled" > units). As such, if you say in your layout (or drawable graphics > description) that you want a line or spacing of 1 density pixel, that > will be converted for you to 1 pixel or 2 pixels or however many > pixels on the screen is appropriate for the actual density. > > - Apple's UI design has a certain design aesthetic of "lots of anti- > aliasing to more accurately represent the position of lines being > drawn at the expense of blurrier pixels," driven in part by the > coordinate system not being pixel-based. There are certainly many > people who like it, but there are also many people who like rendering > that does hinting and aligning of figures to reduce the impact of anti- > aliasing. I think it's pretty extreme to promote one approach or the > other as being the one true way. For Android, we have made the > decision to use some hinting in our font rendering for crisper text, > and likewise density adjustment happens at the view layout level and > then the raw 2d rendering operates on pixels on the screen so that it > can round coordinates to pixel boundaries as desired. > > > > create an application, it has to be prepared to run on all processor > > > speeds, all screen sizes, etc. > > this is your assumption (as an application developer?) As a handset > > manufacturer, your viewpoint is different. You want to produce > > something with specific capabilities. If Android cant cater to your > > needs, then you choose something that can. Lost market share for > > android. > > Actually, from what I can see, what handset manufacturers want is: > > (1) As high a density of screen as possible (since this is a big > marketing bullet in comparison to other phones). > (2) As slow a CPU as possible (since this saves money and power and is > much harder for people to understand as marketing bullet). > (3) Oh and we'll throw in a basic 3d hardware accelerator for you > (since that can create some snazzy marketing demos). > > In such an environment, a bitmap/raster-based UI is going to be far > superior to one based on scalable graphics, because you basically have > to use the 3d hardware to do any smooth rendering to the screen (the > CPU just isn't sufficient), and that thing isn't going to be able to > efficiently render path-based graphics. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
