Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

iPhone 6 Screens Demystified

paintcodeapp.com

Post reply on HN
Print view View original

81–88 of 88 posts

Re: iPhone 6 Screens Demystified

#81

Post by runeks »

u124556 wrote: post #35

So if you want to watch a 1080 video on this device, the player will upscale it to 1242 and then the hardware will downscale it to 1080 again? or will there be some way to bypass all this?

This article concerns "rasterization": the process of converting a description of an image into actual pixels.

A 1080p video stream doesn't need rasterizing -- it already consists of pixels. Any sane video player would simply show the original 1080p video mapped on the 1080p screen in full screen mode.

Re: iPhone 6 Screens Demystified

#82

Post by runeks »

adamfeldman wrote: post #15

(1) Is it really a problem that apps can't be pixel perfect on the 6+? How unsharp are we talking about? Are there workarounds such as device detection and an additional set of image assets? (2) Will Apple aim to re-enable pixel-perfection in next year's iPhone release? Was this just a stopgap measure due to yield challenges inherent to display manufacturing?

My Nexus 5 (4.95", 1080p, 445 ppi) does the same, and to me it looks fine.

See my other post in this thread: https://news.ycombinator.com/item?id=8308194

Re: iPhone 6 Screens Demystified

#83

Post by rayiner »

ianlevesque wrote: post #78
rayiner wrote: post #18

Earlier quoted context omitted.

I think it's actually pretty clever. Developers clearly have trouble writing apps to support arbitrary scale factors. Resolution independence was supposed to be a feature of Windows since Vista was codenamed "Longhorn" (before 2004), and Windows is still a mess on higher-DPI screens 10 years later. Making it so developers only have to think about 1x and 2x and 3x makes the task easier. Also, look at it this way: with…

1x 2x 3x is great as developer, but downscaling the result to save a few bucks on the display panel? Not so much.

Its not the cost, its the power usage. The 1080p LG G2 had incredible battery life, while the G3 (according to all the reviews) with 2K screen was a big step backward in battery life.

Re: iPhone 6 Screens Demystified

#84

Post by UIZealot »

For the 6+, why couldn't they use a 1600x900 screen at 2x and be done with it? That'd be 800x450 points and 330 dpi, nice and easy. Rendering at 3x and then down sampling to 1920x1080 seems like a lot of useless busy work for absolutely no gain.

Re: iPhone 6 Screens Demystified

#85

Post by tracker1 »

BugBrother wrote: post #57
MCRed wrote: post #40

Earlier quoted context omitted.

I haven't worked in the Kindle division, but there is a huge cultural gulf between Apple and Amazon. Apple is very much a software company (well they're a design company that encompasses both hardware and software). They care a great deal about getting software right. At WWDC each year they have a session on how to do great software that illuminates a process that involves a lot of design and upfront work before you…

>> Nowadays nobody barely thinks about their work before they start writing code, for the most part. I am old enough to remember where this came from... I used to do C for quite a while, then I made my hobby (Perl and scripting) my day job. If given a certain size of a problem while working alone, I used to sit down and think for 1/2 a day or so, then develop (coding and also thinking more) for a week or two. After I…

Absolutely agreed... prototype-morph-prod is a faster cycle.. but on the same lines, it means automated unit tests are more important the more complex projects get. Which is why modular code and testing work really well with scripting environments, and computing is fast enough.

With a modular approach, it also becomes easier to scale horizontally either in the same server/system or a separate server/system. Either via HTTP, TCP, 0mq or another abstraction, if the interfaces are the same, the modular layers can be replaced. This gets easier with async by default environments (node.js, golang, etc), and I find it to be much harder with classic N-Tier (.Net, Java). I'd rather use 0mq with node than wcf with .Net any day of the week.

Re: iPhone 6 Screens Demystified

#86

Post by pfranz »

mpweiher wrote: post #75
pfranz wrote: post #32

Earlier quoted context omitted.

I think the reason raster icons have stuck around so long is the proportions of icons need to change as the scale gets really small to keep them recognizable (I think formats like svg has support for this now). Any vector icons also need to be rasterized before drawing to the screen which can take up memory and make things less speedy. Vector icons were the new hot well before the original iPhone was released. Here's…

> Any vector icons also need to be rasterized before drawing to the screen which can take up memory and make things less speedy. Well...any raster format needs to be read from disk, decoded and drawn, though there are special optimizations for the drawing step.

...any vector format needs to be read from disk, decoded and "rendered" (bezier, gradients, transparency, etc calculated), too.

Re: iPhone 6 Screens Demystified

#88

Post by BugBrother »

tracker1 wrote: post #85
BugBrother wrote: post #57

Earlier quoted context omitted.

>> Nowadays nobody barely thinks about their work before they start writing code, for the most part. I am old enough to remember where this came from... I used to do C for quite a while, then I made my hobby (Perl and scripting) my day job. If given a certain size of a problem while working alone, I used to sit down and think for 1/2 a day or so, then develop (coding and also thinking more) for a week or two. After I…

Absolutely agreed... prototype-morph-prod is a faster cycle.. but on the same lines, it means automated unit tests are more important the more complex projects get. Which is why modular code and testing work really well with scripting environments, and computing is fast enough. With a modular approach, it also becomes easier to scale horizontally either in the same server/system or a separate server/system. Either vi…

Interesting point about scaling, thanks.
Post reply on HN