489.44 KB, application/zip
Bug 1283909 - Replaces start menu tile images with larger versions to provide better resoultion on HiDPI screens.
58 bytes, text/x-review-board-request
167.71 KB, image/jpeg
153.41 KB, image/jpeg
Following up on bug 1232679, we need hidpi and high contrast images for Firefox's in Windows 10's start menu. Dolske's comment on the previous bug sums up the images we still need (we have the small and medium size images): https://bugzilla.mozilla.org/show_bug.cgi?id=1232679#c36 We will need these images for all the varieties of Firefox (Aurora, Nightly, Official and Unofficial).
Katie, can you get me the list of sizes that these icons should be? Can you also research what it means for these to be "high contrast"? Would we be OK with using a high contrast background color on the tile? Is there a system keyword that will use the system's high contrast background color?
Flags: needinfo?(mverdi) → needinfo?(kbroida)
Here's what I've found for the images we need: There should be two types of "high contrast" images: white icon with a black background or black icon with a white background. As far as I can tell, the system keyword that makes Windows choose a certain image to show in the tile should be a part of the name or folder structure. For example, placing an image in a folder called "contrast-black" or "contrast-white" would signal to Windows 10 to use those tile images for a computer set to either of these contrast settings. I'm basing this off of the documentation below: https://msdn.microsoft.com/en-us/library/windows/apps/dn393983.aspx#specify_images_for_scaling__localization__and_high_contrast https://msdn.microsoft.com/en-us/library/windows/apps/hh965372.aspx#Contrast Here is a listing of images and sizes we need based off their example in the first link above and on this documentation: https://msdn.microsoft.com/en-us/windows/uwp/controls-and-patterns/tiles-and-notifications-app-assets#High-contrast_assets 150x150Logo.scale-80.png -- 120x120 150x150Logo.scale-100.png -- 150x150 (we have this one) 150x150Logo.scale-140.png -- 210x210 150x150Logo.scale-180.png -- 270x270 70x70Logo.scale-80.png -- 56x56 70x70Logo.scale-100.png -- 70x70 (we have this one) 70x70Logo.scale-140.png -- 98x98 70x70Logo.scale-180.png -- 126x126 The sizes for the images below will be the same for the same scales above. For example, we need the 150x150Logo.scale-80_contrast-white.png to be 120x120. 150x150Logo.scale-80_contrast-white.png 150x150Logo.scale-100_contrast-white.png 150x150Logo.scale-140_contrast-white.png 150x150Logo.scale-180_contrast-white.png 150x150Logo.scale-80_contrast-black.png 150x150Logo.scale-100_contrast-black.png 150x150Logo.scale-140_contrast-black.png 150x150Logo.scale-180_contrast-black.png 70x70Logo.scale-80_contrast-white.png 70x70Logo.scale-100_contrast-white.png 70x70Logo.scale-140_contrast-white.png 70x70Logo.scale-180_contrast-white.png 70x70Logo.scale-80_contrast-black.png 70x70Logo.scale-100_contrast-black.png 70x70Logo.scale-140_contrast-black.png 70x70Logo.scale-180_contrast-black.png For more examples, I also found this documentation helpful: https://msdn.microsoft.com/en-us/library/windows/apps/jj552943.aspx In terms of how we organize this, should we stick to having the keywords in the name of the files or in the folder structure? My preference is folder structure and shorter file names, but I don't think there is a technical reason for choosing one or the other. Let me know if I've missed anything!
I'm not sure what to do about the high contrast images since we don't make the Firefox icon in black & white.
3 years ago
Assignee: nobody → kbroida
Status: NEW → ASSIGNED
(In reply to (unavailable 07/20-07/21) Jared Wein [:jaws] (please needinfo? me) from comment #3) > I'm not sure what to do about the high contrast images since we don't make > the Firefox icon in black & white. We should probably use the single color metro icon. Right now we just use the regular icon in high contrast mode.
I believe the updated decision from shorlander was to _not_ use a different icon. I think the argument was that the normal icon already has adequate contrast, and using a different hi-contrast icon is mostly only useful for apps using flat 1-color icons (eg you'd need to use a white icon in the black mode, and a black icon in the white mode).
At different scales, the Resources.pri file will tell Windows which of them images to use. I've created a new folder (win10Logo) for all of the images and supporting files. The win10LogoConfig.xml file is what I used to generate the Resources.pri file using makepri.exe. I figured saving those settings will be helpful to anyone that needs to re-generate Resources.pri. I also found that having all of the image files in a default language folder (en) was necessary for generating only one Resources.pri file instead of multiple for each image scale. Review commit: https://reviewboard.mozilla.org/r/67554/diff/#index_header See other reviews: https://reviewboard.mozilla.org/r/67554/
Comment on attachment 8775385 [details] Bug 1283909 - Replaces start menu tile images with larger versions to provide better resoultion on HiDPI screens. https://reviewboard.mozilla.org/r/67554/#review65106 Tentative r+ once you can confirm that this works on other locales. ::: browser/branding/aurora/win10Logo/win10LogoConfig.xml:10 (Diff revision 1) > + <autoResourcePackage qualifier="Scale"/> > + <autoResourcePackage qualifier="DXFeatureLevel"/> > + </packaging> > + <index root="\" startIndexAt="\browser\VisualElements"> > + <default> > + <qualifier name="Language" value="en-US"/> Can you include a comment that says the Language here is only an implementation detail and should not change per build? Also, have you tested on a non-en-US build of Windows×Firefox? The QA team may be able to help you here. You can needinfo "Michelle Funches - QA" and she should be able to help you out. ::: browser/branding/aurora/win10Logo/win10LogoConfig.xml:18 (Diff revision 1) > + <!--<index startIndexAt="Start Index Here" root="Root Here">--> > + <!-- <indexer-config type="resfiles" qualifierDelimiter="."/>--> > + <!-- <indexer-config type="priinfo" emitStrings="true" emitPaths="true" emitEmbeddedData="true"/>--> > + <!--</index>--> Can these lines be deleted? ::: browser/branding/branding-common.mozbuild:18 (Diff revision 1) > if CONFIG['MOZ_WIDGET_TOOLKIT'] == 'windows': > FINAL_TARGET_FILES['..'] += [ > - 'firefox.VisualElementsManifest.xml', > + 'win10Logo/firefox.VisualElementsManifest.xml', > + 'win10Logo/Resources.pri', > ] > - FINAL_TARGET_FILES.VisualElements += [ > + FINAL_TARGET_FILES.VisualElements.en += [ Please include a comment stating that this locale "en" is only an implementation detail of the Microsoft tool and does not need to change per locale build.
Thank you for the feedback, Jared. Michelle, what is the best way I can go about building Firefox for other locales? Is there any documentation in particular I should take a look at?
Hi Katie, I am not the correct person to answer your question as I dont build and develope. I would start with the MDN Mozilla Developer Network Build Configuration info (https://developer.mozilla.org/en-US/docs/Mozilla/Developer_guide/Build_Instructions/Simple_Firefox_build#Build_configuration_(optional)) I will update this if I get specifics
Also Katie; let us know if we can test anything for you. We have several people in our office that are bilingual.
Hi Katie, here is an update -here's one example link: http://archive.mozilla.org/pub/firefox/nightly/2016/07/ -if you choose one that ends with "-l10n" there will be versions for different locales in that folder Also there are downloadable builds for Aurora and Beta
Hi Michelle, this all makes sense. Thank you for pointing me in the right direction. I'll work on this and get in touch if I have more questions.
You're welcome Katie, I will close this out as works for me. Please reopen if you need to, or ping me on IRC michelle-qa
Status: ASSIGNED → RESOLVED
Last Resolved: 3 years ago
Resolution: --- → WORKSFORME
Oops, sorry Michelle. I haven't quite finished working on this patch yet, so I'll re-open it for now :)
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
(In reply to Jared Wein [:jaws] (please needinfo? me) from comment #8) > Comment on attachment 8775385 [details] > Bug 1283909 - Adds images and Resources.pri file to improve Firefox's start > menu tile appearance on hidpi screens. > > https://reviewboard.mozilla.org/r/67554/#review65106 > > Tentative r+ once you can confirm that this works on other locales. > > ::: browser/branding/aurora/win10Logo/win10LogoConfig.xml:10 > (Diff revision 1) > > + <autoResourcePackage qualifier="Scale"/> > > + <autoResourcePackage qualifier="DXFeatureLevel"/> > > + </packaging> > > + <index root="\" startIndexAt="\browser\VisualElements"> > > + <default> > > + <qualifier name="Language" value="en-US"/> > > Can you include a comment that says the Language here is only an > implementation detail and should not change per build? WTF? Why is a language necessary at all then?
Because the Microsoft tool requires it
(In reply to Mike Hommey [:glandium] from comment #16) > > WTF? Why is a language necessary at all then? I needed to create a Resources.pri file that specifies which images should be used at different scales (see the documentation linked below). https://msdn.microsoft.com/en-us/library/windows/apps/dn393983.aspx#Specify_images_for_scaling__localization__and_high_contrast Unless I set a default language, Microsoft's makepri.exe tool generated multiple PRI files for different scales instead of one that covered all the information we need. I couldn't find a reason why this was happening through my own troubleshooting, after reaching out to some people at Microsoft and after posting on Stackoverflow (I've linked to that below as well if you want more details on the issue): http://stackoverflow.com/questions/38506783/why-is-makepri-exe-creating-more-than-one-resources-pri-file I assumed that we would only want to add one Resources.pri file in this patch for simplicity/size reasons. However, we could just skip the default language and add the three files makepri.exe created (one for both scales 100 and 80, one for 140 and one for 180). If I'm missing something about how makepri.exe should work please do let me know. The underlying issue hasn't been obvious to me so far.
In testing this patch for computers with a non-English default language, I found that this patch breaks the start tile image (but not the background color or name) on English language computers. I'm going to clear the review for this for now, especially since solving bug 1291331 might be a better next step to make sure everyone can see the tile (even if in low dpi).
Jared and I did some digging into this HiDPI issue and found a number of things, including a solution! More details below: 1) To use Windows's Resources.pri system, you need to have one Resources file Not including a default language creates three resources.pri files (as mentioned previously), but not all of these resources.pri files apply for their scale. In other words, makepri.exe creates these three files by default: Resources.pri Resources.scale-140.pri Resources.scale-180.pri but Windows only uses the file named Resources.pri and ignores the other two files/scales. We found this was the case by putting a number on all of our logo images in Microsoft Paint, changing the computer's scale, triggering a tile refresh via Powershell, and then checking to see which numbered image is applied. At 100% scale, the 100% image applied, but this was also the case at the 200% scale unless we renamed our Resources.pri file (which covered scales 100% and 80%) to oldResources.pri and then renamed Resources.scale-180.pri to Resources.pri. Then the 180% scale image applied to the tile when the computer was 200% scale and at 100%. Apparently Windows will only use what is in Resources.pri and will ignore everything else. 2) Forcing makepri.exe to generate one file with a default language breaks the tile When we set "en" to be the default language and created just one Resources.pri file, Windows didn't seem to apply it. Instead it just seems to break the image's relative path and no image displays on the start menu tile. The custom background color still applies though. 3) Solution: just use an image scaled for 180% resolution We found that Windows will indeed scale down larger images for their start menu tiles ( https://msdn.microsoft.com/en-us/library/windows/apps/dn393983.aspx#specify_images_for_scaling__localization__and_high_contrast ). When we used a larger image, it did display better at 200% scale and also didn't break/looked fine at 100% scale. My next patch will be to replace the smaller tile images with larger versions. Since we don't need Resources.pri to do more than scale images (ie there is no other versions for other languages or contrasts), it doesn't seem necessary to try to get Resources.pri working. 4) There is a small but noticeable quality difference for larger images on HiDPI screens I'll add some attachments showing the difference, but the lights at the edges of the countries are more defined for the HiDPI tile.
(In reply to Katie Broida [:ktbee] from comment #20) > 3) Solution: just use an image scaled for 180% resolution > We found that Windows will indeed scale down larger images for their start > menu tiles Yeah, this sounds good enough. Maybe we'll eventually need/want to get this fully working, but a single image that's downscaled will be quite fine virtually all of the time. (Especially since even at 100% scaling it's still a decently sized image, 70x70 or 140x140. If we were downscaling to a tiny image size, like 16x16, this could be more of a problem.)
Comment on attachment 8775385 [details] Bug 1283909 - Replaces start menu tile images with larger versions to provide better resoultion on HiDPI screens. https://reviewboard.mozilla.org/r/67554/#review69552 r=me
https://hg.mozilla.org/integration/fx-team/rev/5cba4a9fe4de786814cc464bdeb8de6ca3ea9329 Bug 1283909 - Replaces start menu tile images with larger versions to provide better resoultion on HiDPI screens. r=jaws
3 years ago
Status: REOPENED → RESOLVED
Last Resolved: 3 years ago → 3 years ago
status-firefox51: --- → fixed
Resolution: --- → FIXED
Target Milestone: --- → Firefox 51
You need to log in before you can comment on or make changes to this bug.