Closed Bug 766015 Opened 13 years ago Closed 11 months ago

Need highres icons / images for Retina displays

Categories

(Camino Graveyard :: General, defect)

Product:
Camino Graveyard
Component:
General
Platform:
x86
macOS
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED INCOMPLETE

People

(Reporter: phiw2, Unassigned)

References

Details

Attachments

(7 files, 1 obsolete file)

A couple tabs and bookmark manager
517.26 KB, image/jpeg
Details
Safari favicons
122.20 KB, image/jpeg
Details
stop-reload-back-forward icons (wip2)
50.14 KB, application/zip
Details
screenshot with large icons
278.22 KB, image/png
Details
screenshot with small icons
267.72 KB, image/png
Details
screenshot: wip v3
444.46 KB, image/png
Details
Screenshot for Comment #26
99.94 KB, image/jpeg
Details
Fwiw: [12:02] skered: Thank god for Camino being a native app. It looks good on the Retina MBP (minus the icons). [12:03] phiw2: Yeah, the icons certainly need some work [12:04] phiw2: How crisp is the rendering of text ? [12:04] skered: Very [12:04] phiw2: (compared to Safari) [12:04] skered: The same [12:04] phiw2: oh, that is good then
I was a bit worried about how our tabs look too. Would love to see a screenshot of just the bookmark manager with a bunch of toolbar icons and two tabs open.
(In reply to Samuel Sidler (:ss) from comment #2) > I was a bit worried about how our tabs look too. Would love to see a > screenshot of just the bookmark manager with a bunch of toolbar icons and > two tabs open. dereks ^^^ ----- (In reply to philippe from comment #0) > References: > https://developer.apple.com/library/mac/documentation/userexperience/ > conceptual/applehiguidelines/IconsImages/IconsImages.html Ugh, so we have to rename all of our images :-( And switch from .icns to .png for the Finder icons? That sucks, and sounds like it's going to "break" smaller sizes on non-10.7. Oh, no, we just have to give them crazy member names and then repack with iconutil/tiffutil: https://developer.apple.com/library/mac/#documentation/GraphicsAnimation/Conceptual/HighResolutionOSX/Optimizing/Optimizing.html#//apple_ref/doc/uid/TP40012302-CH7-SW3 And then I guess make sure that the older OS versions pull the right members based on size, not member name. ----- Note that, beyond our icons/images, some web content stuff won't work, e.g. bug 765914, bug 763918, but otherwise, by not moving beyond Gecko 1.9.2, we prevented text from being fuzzy, since Gecko's Layers are broken (bug 674373) :P The other thing that's likely going to be bad is site icons; given all the bugs we have with them, I'm not sure that displaying a site's HiDPI version in HiDPI mode going to be an easy fix. Any HiDPI site icon issues are deserving of a separate bug, anyway.
By Comment #2 request
(In reply to Smokey Ardisson (not following bugs - do not email) from comment #3) > Ugh, so we have to rename all of our images :-( No, not really. It is more complicated… 1. toolbar icons and the like - a quick test showed that tiffutil doesn't like it at all to have 32x32* and 24x24* images in the same file. 2. for the icns files there should be no problem at all, package them with iconutil and that should be fine for all OS. (aside: iconutil appears to do a better job at compressing images than Icon Composer does). In addition, Apple recommends that all images are tagged with an sRGB profile… I'll attach a couple of Proof Of Concept images later today or so. I wonder how Apple handles some of their own apps. I checked the bundles for Adress Book, Preview, Mail (all those were updated with 10.7.4 and contain HiDPI icns files). They all use .PNG images for e.g. the preference panes (one size - unless Apple added more images for the Retina MBP OS). > Note that, beyond our icons/images, some web content stuff won't work, e.g. > bug 765914, bug 763918, but otherwise, by not moving beyond Gecko 1.9.2, we > prevented text from being fuzzy, since Gecko's Layers are broken (bug > 674373) :P Bug 765914 doesn't affect us anyway, Gecko 1.9.2 doesn't support that device-pixel-ratio media queries (which pains me immensely sometimezzz, as a web author). > The other thing that's likely going to be bad is site icons; given all the > bugs we have with them, I'm not sure that displaying a site's HiDPI version > in HiDPI mode going to be an easy fix. Any HiDPI site icon issues are > deserving of a separate bug, anyway. Yeah, that is another bug anyway. In bug 530249 comment 3, I pointed to the relevant html5 spec entry. That doesn't take HiDPI into account… (spec running behind the times…). How do favicons look like in Safari's location bar ?
Attached image Safari favicons —
You can see a big difference between Safari (left) and Camino (right) for CNN however the Apple favicons appear the same?
(In reply to Derek Schrock from comment #6) > Created attachment 634659 [details] > Safari favicons > > You can see a big difference between Safari (left) and Camino (right) for > CNN however the Apple favicons appear the same? Apple serves a 32x32px favicon.ico from the root, CNN serves a 48x48px favicon.ico. I guess (hope !) the favicon for http://l-c-n.com/ appears crisp in both browsers (it is a 32x32px PNG image). caminobrowser.org is a 16x16px image. I'll make a 32x32px image soonish.
(In reply to philippe from comment #5) > 1. toolbar icons and the like - a quick test showed that tiffutil doesn't > like it at all to have 32x32* and 24x24* images in the same file. Really? Our current toolbar icons are 32x32 and 24x24 in the same file, and tiffutil is what Apple's doc I linked to say to use… Or do you mean that tiffutil doesn't like 32, 32@2x, 24, and 24@2x (which seems like an Apple bug, given their docs…).
(In reply to Smokey Ardisson (not following bugs - do not email) from comment #8) > Really? Our current toolbar icons are 32x32 and 24x24 in the same file, and > tiffutil is what Apple's doc I linked to say to use… Or do you mean that > tiffutil doesn't like 32, 32@2x, 24, and 24@2x (which seems like an Apple > bug, given their docs…). this is what tiffutil spits out: $ tiffutil -cathidpicheck back-32.png back-32.png back-24.png back-24@2x.png -out back.tiff Warning: Sizes of concatenated images do not follow Aqua guidelines for resolution independent multi-image TIFFs. Please provide two images, one with exactly twice the pixel width as the other. Image 1 in file back-32.png: 32x32 points (32x32 pixels, 72x72 dpi) Image 1 in file back-32.png: 32x32 points (32x32 pixels, 72x72 dpi) Image 1 in file back-24.png: 24x24 points (24x24 pixels, 72x72 dpi) Image 1 in file back-24@2x.png: 48x48 points (48x48 pixels, 72x72 dpi) 4 images written to back.tiff. If I stick that image inside the Camino bundle, it works fine on 10.7 and non-HiDPI.
… And I should mention, with HiDPI through Quartz-debug, the image looks crisp (looks crap because it is just a quick resize without much fine-tuning or anything, but hey…) (840x525 screen)
Attached image screenshot: a hidpi back button - wip (obsolete) —
An archive with a first set of icons for testing: stop, reload, back and forward. (to use: put in the bundle: Camino.app > Contents > Resources). Looks pretty decent here both under HiDPI and normal mode. ---- I wonder which icons I should prioritise (time allowing). Obviously most of what appears in the location bar - feed, lock, bookmark manager icon, blank file icon, the default globe thingie (that one is a mess…), and on the bookmark bar; the 4 icons linked above. Then maybe the preference panes? I had a quick look at the app icon in the Finder; that looks mostly decent afaict (OS X interpolation based on available sizes).
Attachment #634736 - Attachment is obsolete: true
Looking at the search box, there is a lot of fuzzyness in there :-(
(In reply to philippe from comment #12) > I wonder which icons I should prioritise (time allowing). Also the tab bar (that is not much work, I _think_).
I'd say, prioritize for the defaults of the main window (default toolbar icons, location bar, search bar, bookmark bar, tab bar), then bookmark/history manager, then preferences, then secondary toolbar items. (We can probably argue about whether preferences or secondary toolbar items should come first... But the order doesn't matter too much by that point.)
(In reply to Samuel Sidler (:ss) from comment #16) > I'd say, prioritize for the defaults of the main window (default toolbar > icons, location bar, search bar, bookmark bar, tab bar), then > bookmark/history manager Agreed. > then preferences, then secondary toolbar items. > (We can probably argue about whether preferences or secondary toolbar items > should come first... But the order doesn't matter too much by that point.) It's a bit academic, yes, but I'd argue that we should do secondary toolbar items before prefPanes, because people who use those secondary toolbar items will see them every single minute of every day, whereas prefs are things that users see rarely. After that, we have assorted images running around in the security UI, the search engine manager UI, and so forth.
(In reply to philippe from comment #9) > (In reply to Smokey Ardisson (not following bugs - do not email) from > comment #8) > > > Really? Our current toolbar icons are 32x32 and 24x24 in the same file, and > > tiffutil is what Apple's doc I linked to say to use… Or do you mean that > > tiffutil doesn't like 32, 32@2x, 24, and 24@2x (which seems like an Apple > > bug, given their docs…). > > this is what tiffutil spits out: > $ tiffutil -cathidpicheck back-32.png back-32.png back-24.png back-24@2x.png > -out back.tiff > Warning: Sizes of concatenated images do not follow Aqua guidelines for > resolution independent multi-image TIFFs. > Please provide two images, one with exactly twice the pixel width > as the other. > Image 1 in file back-32.png: 32x32 points (32x32 pixels, 72x72 dpi) > Image 1 in file back-32.png: 32x32 points (32x32 pixels, 72x72 dpi) > Image 1 in file back-24.png: 24x24 points (24x24 pixels, 72x72 dpi) > Image 1 in file back-24@2x.png: 48x48 points (48x48 pixels, 72x72 dpi) > 4 images written to back.tiff. What if you -cathidpicheck 32 and 32@2x into one file, -cathidpicheck 24 and 24@2x into another file, and then normal -cat those two files? (Or does the warning message appear to be spurious and the 4-member toolbar button TIFF it generates actually work OK?)
(In reply to Smokey Ardisson (not following bugs - do not email) from comment #18) > (Or does the warning message appear to be spurious and the 4-member toolbar > button TIFF it generates actually work OK?) Have a look at the two most recently attached screenshots ? It does work ok, at least in my HiDPI simulation. (In reply to Smokey Ardisson (not following bugs - do not email) from comment #17) > (In reply to Samuel Sidler (:ss) from comment #16) You do realize, I hope, that this something that will take quite a while ? Especially given that: * most images have to be reverse engineered to figure out colors, gradients and transparency (lack of source files, :-p) * scaling the images is just one part of the work. After scaling some fine tuning is needed (except where the image is a square). * looking at those images in simulation mode is one thing, it doesn't necessarily mean that it looks good on an actual hiDPI device (or how the user perceives it). It is similar as looking at an in-development app or a webpage in the iOS 5.x / new iPad / iPhone4s simulator and looking at those on a real iPad. (mecenas, $anonymous donor welcome to buy me a retina MBP)
(In reply to philippe from comment #19) > (In reply to Smokey Ardisson (not following bugs - do not email) from > comment #18) > > (Or does the warning message appear to be spurious and the 4-member toolbar > > button TIFF it generates actually work OK?) > > Have a look at the two most recently attached screenshots ? > > It does work ok, at least in my HiDPI simulation. I wasn't sure, because your comment mentioned fuzziness--although re-reading it now I see it was just about the search field ;-) I did see the screenshots, and I thought they looked OK, but (also) not having a HiDPI environment I don't know what to compare them to ;-) > (In reply to Smokey Ardisson (not following bugs - do not email) from > comment #17) > > (In reply to Samuel Sidler (:ss) from comment #16) > > You do realize, I hope, that this something that will take quite a while ? Yeah, I was guessing several months, optimistically, thus the "it's a bit academic" as to what's next after the default browser window UI. If we ever do a complete icon refresh again, though, I'm going to insist that Sam includes source files as part of the requirements :P It's been such a pain already, just for the icons you've already fixed once[1], and now we need to go through it all again, for all of them… [1] bug 524330, bug 542958, bug 543284, bug 555147, bug 555148
Attached image screenshot: wip v3 —
Screenshot: wip 3 with: * some fine-tuning the back-forward-reload stop buttons * tab-bar: tab-background, active tab, close button, scroll widgets. My plan at the moment is, for Camino 2.1.3 if possible 1/ getting the back-forward-stop-reload buttons to look good (mostly done) 2/ the tab bar (mostly done) 3/ the icons in the location bar (uh…) 4/ the bookmark manager toolbar icon (only needs scaling) & the small bookmark icon on the BM bar. I'll to open separate bugs for those items above when they are ready. Regarding the globe icon: the current icon is a mess to recreate. Would it be acceptable to use a different one ? I have an alternate that might be acceptable - it is visible on the left most tab in the screenshot (still need some polish).
(In reply to philippe from comment #21) > Regarding the globe icon: the current icon is a mess to recreate. :-( > Would it be acceptable to use a different one ? Maybe? > I have an alternate that might be > acceptable - it is visible on the left most tab in the screenshot (still > need some polish). I don't like that one so much; it's much darker and a very different shade of blue. :-( ---- Regarding the search field fuzziness (which I see really clearly in wip v3); is the search icon crisp on a site that doesn't have OpenSearch? As I recall, we're doing some sort of compositing of the icon and the blue field, and that code seems like it's going to have to be rewritten to account for HiDPI, if we can detect when we're in HiDPI… I don't think we're doing compositing for the no-OpenSearch-detected case, so I'd hope the magnifying glass would be crisp there…. We'll need a new bug for the code changes, whether both states need it or only one. In any case, if there are places where you guys can tell the problem is all/partly in code, go ahead and file bugs, and if there are enough of them, we can hang them off a new meta (I don't want to reuse bug 351709, since those all seem like different types of issues than what we're seeing with HiDPI so far).
The icon looks crisp in each case: non-opensearch and opensearch sites. Also, the icon looks identical to Safari's search field.
On thing I noticed while looking at web content in HiDPI mode is that form controls don't look crisp (they are slightly pixelated). In the preference panes, those thingies look perfect. I suspect there is nothing we can about that given the current code base, though (that is all Cocoa Widgets managing this, right ?)
(In reply to Derek Schrock from comment #23) > The icon looks crisp in each case: non-opensearch and opensearch sites. > Also, the icon looks identical to Safari's search field. OK, that's good! The blurriness we see in philippe's screenshots must be an artifact of either the simulator or the screenshot mechanism :-) (In reply to philippe from comment #24) > On thing I noticed while looking at web content in HiDPI mode is that form > controls don't look crisp (they are slightly pixelated). In the preference > panes, those thingies look perfect. > > I suspect there is nothing we can about that given the current code base, > though (that is all Cocoa Widgets managing this, right ?) Yeah, and Cocoa Widget is doing all sorts of playing around with sizes on top of that. (In reply to philippe from comment #7) > (In reply to Derek Schrock from comment #6) > > Created attachment 634659 [details] > > Safari favicons > > > > You can see a big difference between Safari (left) and Camino (right) for > > CNN however the Apple favicons appear the same? > > Apple serves a 32x32px favicon.ico from the root, CNN serves a 48x48px > favicon.ico. It's unclear why the Apple site icon appears the same, but the general problem with our using scaled-up 16px members when sites provide 32px members in their .ico files is bug 767661. (If a site provides 16px and 32px in two different files, that's a whole other s/mess/bug/g!) > caminobrowser.org is a 16x16px image. I'll make a 32x32px image soonish. Bug 766418 (fixed for cbo and cpo), but it still won't look good in Camino until we fix the aforementioned bug 767661.
Depends on: 767763
Depends on: 767764
I ran into a weird icon display when testing HiDPI icons that appear in the bookmark manager. Basically the HiDPI icon is used, but displayed at twice the size of its allocated space (both icons display correctly in other locations). Could be an issue with HiDPI mode, though. Screenshot (in HiDPI mode): http://dev.l-c-n.com/camino/_d/bm-manager-icons.png If this is reproducible on a retina MBP, a bug should be filed. Here are two icons for testing (WIP, I'm aware of a number of issues with the smallbookmark.tiff file; history_icon.tiff is more or less finished). http://dev.l-c-n.com/camino/_d/_loc_bm-test.zip
Duplication of icon displaying at twice the size on a Retina MBP
Depends on: 768757
(In reply to Derek Schrock from comment #27) Thanks for confirming this. I filed bug 768757.
Depends on: 770808
Depends on: 770809
Depends on: 771035
Depends on: 771494
Depends on: 785281
Depends on: 794324
Depends on: 796899
Depends on: 800345
Status: NEW → RESOLVED
Closed: 11 months ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: