Hacker News new | past | comments | ask | show | jobs | submit login

Windows XP at 2560x1600 is ok on my 30" monitor, but it would be next to unusable on a 15" display. The Icons didn't scale to the resolution, so they would have been tiny.

Lots of screen real estate though.




2560x1440 on my 27" iMac is ok, but I have to use CMD-+ on almost all web pages. Only in Safari is Magic Touchpad zooming smooth and iOS like, but I'd like to use Chrome.

With 175% zoom I get some weird(and reported) errors in Chrome: http://imgur.com/TCDMj

The HiDPI solution in ML is not really a solution for resolutions that are somewhere in-between normal DPI and HiDPI.


If your eyesight isn't good enough to handle low-DPI, you may want to investigate the accessibility control panel.


There's nothing there to force a minimum font size.


Because that would break every app. But you can zoom the whole screen.


Yes, and that is exactly the problem. The iMac's size and resolution is awkward-DPI.

I enabled HiDPI mode, but then I got 1280x720 on 27"... And without it much of the texts on web pages are too small.

You make it sound like I'm blind or something. I'm just tired of reading far too small texts.


I'm pretty sure HiDPI mode and accessibility zooming are not the same thing.

100 DPI is pretty much the industry standard, so if it feels awkward to you then it's not a problem with the iMac per se.


The size of the display makes you increase the distance, or one would get chronic neck pain quite fast. :)


Are you running Windows XP under BootCamp? I could see Windows XP being okay at 27" @2560x1440.


No, Mountain Lion. I am a bit disappointed since NeXT had Display Postscript back in the 80s and today we use bitmap icons far too much.


NeXT had bitmap icons (TIFFs) displayed using display postscript. The problem with vector graphics in icons is that you'll still need multiple versions for different resolutions or the icons will look terrible at most resolutions, and then it's horribly inefficient to render them on-the-fly all the time so you'll end up caching them in memory and rescaling them... and -- oh look -- bitmaps.


Well, eventually it's going to come out as a bitmap—they'll still end up as pixels on the screen. Vector icons just give you the flexibility to do it really really well. Cache them, prerender them, I don't care what works best, just match the icon DPI to the screen DPI and we're good.


His point is that it's not good enough to simply match the DPIs and render. Small icons need actual visual differences, not just scaling, in order to really look good. Some icons completely change their character at small sizes, because what looks good when small is not the same as what looks good when large, regardless of DPI. So going pure-vector doesn't completely solve the problem, although it certainly can make it easier.


There is that, and there is also the quality of how aliasing is handled by real time vector art renderers. We just aren't their yet to be relying on vector art for icons (even though they start out that way in Illustrator).


That's true at low-DPI, but not so much at high-DPI. I wonder if a bundle of low-DPI bitmap + a vector for high-DPI would work better than the standard practice of bundling multiple bitmaps...


I think it's still true, although less so. Certainly a certain amount of fiddling takes place in an attempt to align to pixels etc., but sometimes icons just need to change at different physical sizes. Small elements may need to be enlarged to remain visible and such.


But by chosing a certain style to all UI elements, vector icons could look and feel just smashing anyway.


Quartz2d is effectively "Display PDF". Bitmap icons are necessary (at least in the icon portfolio) as they can degrade more gracefully at lower pixel counts.

NeXTStep/OpenStep used bitmap icons.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: