Got a tip for us?
Let us know
Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
Apple Patent for Resolution Independent User Interface
- Thread starter MacRumors
- Start date
- Sort by reaction score
LOL, funny to see how few people know what resolution independence does. LCD-Display all have a certain number of dpi (dots per inch). Usually it's 72, 75 or 100 for laptop displays. When you look closely at your screen, you can see those little squares, each of those squares has 3 rectangles (red, green and blue, mixed together you get a square in every color you want). As it is now, cranking up the resolution makes everything smaller, to a point where it's hard to read, click buttons etc. And changing the resolution of a LCD-Display to something different than its native resolution (the one that corresponds to the number of pixels the display actually has), looks terrible.
Resolution independence makes it possible to scale things without changing the resolution. If you have to squint sometimes, make it bigger, if you wish to have more space for windows, make it all smaller. Resolution independence lets you zoom in without getting blurry and loosing details. Try that zoom function (CTRL+scroll up) and you'll see how bad it looks. With resolution independence, it would still be super sharp (until a certain degree I guess). You can't convert everything into vectors or have pictures with infinite resolution, but it should be enough to double or triple the resolution on LCD-Displays. You can't really buy any of those displays yet because you wouldn't be able to read anything without a magnifying glass right now, but who knows, Apple might present new high res displays after Leopard is out giving you super sharp pictures.
Resolution independence makes it possible to scale things without changing the resolution. If you have to squint sometimes, make it bigger, if you wish to have more space for windows, make it all smaller. Resolution independence lets you zoom in without getting blurry and loosing details. Try that zoom function (CTRL+scroll up) and you'll see how bad it looks. With resolution independence, it would still be super sharp (until a certain degree I guess). You can't convert everything into vectors or have pictures with infinite resolution, but it should be enough to double or triple the resolution on LCD-Displays. You can't really buy any of those displays yet because you wouldn't be able to read anything without a magnifying glass right now, but who knows, Apple might present new high res displays after Leopard is out giving you super sharp pictures.
Yeah Windows versions prior to Vista have a poor mans version of resolution independence since the drawing environment is generally pixel based for those operating system versions.
Vista is switching to a drawing environment similar to what Mac OS X has (actually since Display PostScript in NeXT OS). This type of drawing environment allows applications to draw using a fixed coordinate space (for example in terms of points with a fixed value of some number of points per inch) and then have the drawing environment, based on output context/device, map points to pixels (rasterize) as needed without the application having to care.
Also in some cases the output context could be a vector based device (for example a PDF file) and in that case the drawing environment wouldn't raserize any thing but instead preserve the vector information.
I assume you mean Display PostScript (DPS)? Mac OS X has had Quartz which provides similar (and greater) capabilities as DPS... nothing new is really being added in this space to allow for resolution independence... the changes are mostly at the Carbon and Cocoa levels to break away from the traditional one point equals one pixel for display output devices. Carbon is the framework that will have the most issues with this... unless folks are using the newer HiView stuff.
Thanks for that. Slightly helping. Hope this means that things look nicer! I am not dumb either - just not an artist so wondering how this affects average Joe. Or adam. Or Sam... etc
The control for resolution independence has been available to developers since 10.4 (with various bugs in the Cocoa and Carbon frameworks however stand in the way of full testing).
It means in the future the text, buttons, other UI widgets, etc. you see on your screen will look like a printed page... nice and crisp.
I wouldn't worry... any software worth its salt used for viewing images will likely have a way to view the image with a one to one pixel mapping.
No. If scaling an image makes it look bad, there are two possiblities:
1. Lousy scaling algorithms, which can make an image look blurry or jagged
or
2. Lousy image.
A good photo scaled by a good algorithm will look decent at all resolutions.
I sure hope not. What happens when we get 150-ppi displays? 300-ppi displays?
Your "full-screen" image will become a thumbnail.
Any designer worth his/her salt will have to learn to work at the resolution of the device. It's not terribly difficult: print designers have been doing this for decades. Unfortunately, web browsers are only beginning to allow the necessary controls.
Recall that many mainstream and most/all professional digital cameras capture images at resolutions that current generations of displays cannot fit fully on screen. So when we get 144 or 288 DPI displays we likely still want to see those images without any scaling so we can fit all of the images pixels on the display.
Mac OS X has some of the best image scalers yet developed (resampler) built-in and accelerated using vector operations (AltiVec & SSE). For example Lanczos5, Lanczos3, etc.
If you want pixel accurate image display you would display it with a one-to-one mapping (yeah it may be small but it is accurate) otherwise you would scale it using a good scaler if you didn't care about accuracy. Basically my point is don't worry... all options remain open to developers and they will provide sensible features to customers given their needs.
Well in the case of web designers a lot of what they have made and the tools they use work in terms of pixels. So what they have made may not look as good as it could if they had defined things in terms of "points". In general text and layout should be OK because the browser can cover for them in most cases... the main issue is all of those small highly compressed images that are in use... those won't look good scaled.
Ahh, I agree. Pro-level Image editing software will always let you view at one-to-one.
I'd imagine most image software would do what it does nowmap each pixel of the image to each pixel of the screen at 100%. Just that more of the image could fit on the display at once and it would all be smoother and clearer, and the interface around the image could be any size you like.
These are all pretty elementary concerns peopleanyone with a solid grasp of the concept of fixed vs. variable resolution and screen vs. print resolution knows what the issues are when programming. I wouldn't worry about it.
So true!
When the Mac first came out with 72dpi monitors, what you saw was exactly what was printed. If you took a ruler and measured both (monitor and printout) of an object they would be identical. It was truly WYSIWYG.
I hope this change is very transparent to the user. Especially as someone above mentioned with photos and artifacts. Jesus, I can just see it now for those trying to say oh don't worry about what it looks like on the screen, it will be perfect in print.
If you rasterize your large image to a small number of pixels, it will look bad no matter what you do. Scaling a low resolution image doesn't reflect a problem with scaling, but a problem in the image.
Right now, your images probably already have a DPI value of some kind in them. So if you want to put up a 2" square, you should scale your image to 2" (Photoshop and many others already allow this), leaving the DPI alone. The pixel-dimensions will probably be larger than 144x144, and that's fine. In your web page, specify the dimensions as 2"x2". The web browser (if properly written) will scale the image to the specified size, showing as many or as few pixels as it takes.
Sure, there may be some artifacts if your pixel-resolution is very low, but for normal pictures, it shouldn't be a big deal. Photographs tend to scale very well (compared with line drawings and renderings that don't use antialiassing.) Of course, some programs scale images better than others. Fortuntely, the scaling built-in to Quartz does a very good job most of the time.
Your pages should specify sizes in terms of real-world units (like inches, milimeters, points, etc.) and not in terms of pixels. Leave the conversion up to the web browser. Then you simply have to provide images with enough DPI so they won't get all jagged when shown on a high-DPI display.
I'm just wondering if its possible that different elements of an application could have varying DPIs.
The current resolution independence in Tiger shows that individual windows can have their own DPI values. I wonder if this could be replicated down to individual Cocoa views? So Safari's GUI could be at 120dpi, the actual web page content could be at something lower... Or individual graphic views could be at 72dpi within a 120dpi window?
Interesting....
I'd assume to do this as an automated process the monitor would have to report what it's native pitch is (i.e. dpi). Either that, or when you choose your resolution from the system preferences, you'd have a seperate pop-up menu to select the diagonal screen size, so that the software could calculate your dpi for you.
One of the great things that this will allow is when you choose 100% in a layout program, the visual representation of a layout (for example a 3.5"x 2" business card) will actually scale correctly on the screen. This would be a great help. I can't tell you the number of times that I print something out and am mildly surprised at the actual size of it, after viewing it all day on the screen in what I'm told is scalled at 100%.
One of the great things that this will allow is when you choose 100% in a layout program, the visual representation of a layout (for example a 3.5"x 2" business card) will actually scale correctly on the screen. This would be a great help. I can't tell you the number of times that I print something out and am mildly surprised at the actual size of it, after viewing it all day on the screen in what I'm told is scalled at 100%.
I don't think I can get into specifics (given NDA and Apple not publishing API docs) but again I will say... don't worry ... Apple is giving developers what they need to deal with these types of issues (including time).I'm just wondering if its possible that different elements of an application could have varying DPIs.
The current resolution independence in Tiger shows that individual windows can have their own DPI values. I wonder if this could be replicated down to individual Cocoa views? So Safari's GUI could be at 120dpi, the actual web page content could be at something lower... Or individual graphic views could be at 72dpi within a 120dpi window?
Interesting....
Note some of the API is listed (stuff available in 10.4 at least)...
I'll be very interested to see how well this works out in the finished product.
Eventually, I'm sure all operating systems and web browsers will do this, and most pages will be written to render properly, but that won't be the case in the short term.
Right now, we have a lot of images with incorrect DPI values, because everyone assumes that browsers will render the images at one-pixel-to-one-pixel. So someone may scan a 5" CD cover at 300 dpi (1500x1500), and scale it down to 100x100 pixels, leaving the DPI at 300. When shown today, it renders at 100x100. When shown on a resolution-independent UI, however, those 100 pixels at 300dpi will end up being 1/3 of an inch, displaying as 33x33 on a 100dpi display.
This is going to tick off a lot of people until content creators learn what to do. I this particular case, they need to determine the display size in real units (like 1" square), then scale the image to 1"x1". This would be 300x300 at 300dpi, or 100x100 at 100dpi - the important thing being to set the DPI correctly at the same time the image is scaled. This way, it will render at the same 1" square on all displays.
Of course, overall quality when displayed, will depend on the source image. On a 100dpi display, a 300x300@300 image may look better or wose than a 100x100@100 image (because the scaling algorithm in the displaying-system may be better or wose than the scaling algorithm used to generate the image file). But on a 200dpi display (where 1" square is 200x200), the 300x300@300 image will look a lot better than the 100x100@100 image, because scaling-up tends to produce worse artifacts than scaling-down.
I suppose, as a workaround before web sites are changed, browser software will have to have a setting somewhere to tell it to ignore DPI values in images. Maybe to render all images as if they were 72dpi, or only do this for images that don't have DPI values in them. And maybe allow this setting to be overridden on a per-site basis, to keep resolution-independent-savvy pages looking their best.
Eventually, I'm sure all operating systems and web browsers will do this, and most pages will be written to render properly, but that won't be the case in the short term.
Right now, we have a lot of images with incorrect DPI values, because everyone assumes that browsers will render the images at one-pixel-to-one-pixel. So someone may scan a 5" CD cover at 300 dpi (1500x1500), and scale it down to 100x100 pixels, leaving the DPI at 300. When shown today, it renders at 100x100. When shown on a resolution-independent UI, however, those 100 pixels at 300dpi will end up being 1/3 of an inch, displaying as 33x33 on a 100dpi display.
This is going to tick off a lot of people until content creators learn what to do. I this particular case, they need to determine the display size in real units (like 1" square), then scale the image to 1"x1". This would be 300x300 at 300dpi, or 100x100 at 100dpi - the important thing being to set the DPI correctly at the same time the image is scaled. This way, it will render at the same 1" square on all displays.
Of course, overall quality when displayed, will depend on the source image. On a 100dpi display, a 300x300@300 image may look better or wose than a 100x100@100 image (because the scaling algorithm in the displaying-system may be better or wose than the scaling algorithm used to generate the image file). But on a 200dpi display (where 1" square is 200x200), the 300x300@300 image will look a lot better than the 100x100@100 image, because scaling-up tends to produce worse artifacts than scaling-down.
I suppose, as a workaround before web sites are changed, browser software will have to have a setting somewhere to tell it to ignore DPI values in images. Maybe to render all images as if they were 72dpi, or only do this for images that don't have DPI values in them. And maybe allow this setting to be overridden on a per-site basis, to keep resolution-independent-savvy pages looking their best.
Why not?
I should be able to draw some images at 72dpi, and composite them with some 300dpi scanned images and the system should render the results correctly.
Every bitmap used should have a DPI value of some kind associated with it. And non-bitmap data should already be working in terms of physical units. I think Mac OS has always defined its UI as using points and not pixels, so the hard part will be dealing with developers that didn't understand the difference. (Historically, they were the same for displays, but different for printers. I suspect developers who have written printing code in the past shouldn't have a problem with this change.)
Yup that will be the biggest issue and one reason Apple has been talking to developers about this since before 10.4.
Those using Cocoa should be in the best spot since it much clearer about the difference between points and pixels (was based on the user space / device space model that Quartz and DPS before it had). Those using Carbon will have more issues to tackle given Carbon's history of being QuickDraw based which is generally pixel based.
I think monitors already report this. At least I remember reading about something about the DDC channel (used for plug-n-play) reporting the screen's physical dimensions.
Update: Yes. Plug-n-play monitors report this. The Extended Display Identification Data provided by monitors includes the physical dimensions, in cm. So system software can combine this with the pixel-dimensions of the screen to determine the DPI.
But whatever the dimensions, I hope there will always be a way to override the settings. I happen to like high resolutions (I use a 20" monitor at 1600x1200 at work - 100dpi. Most people I know prefer lower DPIs on their screens.)
There are times where it is useful to know that 1" on screen matches 1" on paper, but there are also plenty of times where you may want to see more content than this, or less content with more detail. Maybe this could be best done with a global zoom control on the menu bar
Leopard is going to be fun. Hopefully, it will be finished soon.