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 -~----------~----~----~----~------~----~------~--~---
