Closed Bug 1050405 Opened 5 years ago Closed 5 years ago
Fix search widget preview
Found an issue on my Nexus 5 where Larry is the icon offered in the widget preview.
Is this a dupe of bug 1050101?
^ looks like it!
Updated after changes in bug 1050403.
Attachment #8470286 - Flags: review?(margaret.leibovic)
Now I'm seeing the older design from Ian in the preview...
Comment on attachment 8470286 [details] [diff] [review] Patch Looks good. But why are there only xhdpi resources? And how did you create these images?
Attachment #8470286 - Flags: review?(margaret.leibovic) → review+
Comment on attachment 8470286 [details] [diff] [review] Patch Actually, it looks like there's still some churn in bug 1050403. Let's hold off on landing this until we reach a final design for the widget. That will save you from more follow-up work :)
Attachment #8470286 - Flags: review+
Was bug 1050403 a dependancy? It's now resolved
(In reply to :Margaret Leibovic from comment #6) > Looks good. But why are there only xhdpi resources? And how did you create > these images? Because I made these by taking a screenshot and then changing the logo in it manaully in GIMP. i.e. kinda awful. I'm not sure if its worth shipping a lot of resolutions here either. This is a placeholder while you're doing the initial drag and drop to add the widget.
35+ assuming that is when we we are shipping the search activity
tracking-fennec: ? → 35+
Can UX generate these for us? My technique (from comment #9) isn't great.
(In reply to Wesley Johnston (:wesj) from comment #11) > Can UX generate these for us? My technique (from comment #9) isn't great. Sure! What kind of assets would you need Wes? I can prep these for you. I'm guessing if I just create .PNGs of the entire image of the widget in MDPI -> XXHDPI that would be good? Let me know. Also, I guess I would prep these in two sets: 1 with Firefox and 1 with Nightly build icons?
Flags: needinfo?(alam) → needinfo?(wjohnston)
Yeah, basically. This is only shown in that preview pane, or while you're dragging from that to your homescreen (i.e. the real widget isn't created until you let go). I made separate ones for release/beta/aurora/central since they will all look different, but release (for release and beta) and nightly (for nightly, aurora, and developer builds) would probably be enough.
This uses the release preview for release/beta and the nightly preview for aurora/nightly/unoffical. This will make it look like there's a bug on Aurora, but it sounds like we're okay with that, since it's just the preview? Also, so many big images :/ Do they really need to be this big for the preview? I see the XXHDPI ones are 1018x176 pixels.
Comment on attachment 8513908 [details] [diff] [review] Add images for search widget preview Make sure these images have been suitably pngcrushed / pngquanted or whatever magic script ckitching used.
Attachment #8513908 - Flags: review?(mark.finkle) → review+
antlam, did you optimize these images? ckitching, what "magic script" should I run on these images?
trimage is the magical script I used from Bug 1054916. It losslessly compresses pngs, which is rather neat. See http://trimage.org/ . As with all of these suggestions, I suggest writing a handy shell script. If you have images that contain no partial transparency you use the tinypng service to win about 10-20% more on top of just using trimage. See https://tinypng.com/ . They provide an API so you can just shove all your PNGs through their system using wget and a for loop. Tinypng is technically a lossy compression algorithm, but in reality it's so negligible that you just can't tell (they have some examples on the homepage - go see). By being very slightly lossy, the optimiser gets to make rather large wins for very tiny quality loss, which is how it's able to apparently do magic. Note that trimage can usually shave a little bit more off of an image after it's been tinypng'd, so it's somewhat worth running both of these where possible. Unfortunately, Android doesn't seem to properly support indexed PNGs with partial transparency, so tinypng will create images that Android is incapable of doing the right thing with if you feed it anything with partial transparency. If you have nine-patches without partial transparency, you could run them through my nine-patch optimiser (or do the equivalent optimisation by hand, which you'll have to do anyway if you've got partial transparency). Someday, I'll fix that thing so it supports partial transparency... See Bug 1048683. Finally, if you do anything manually, prefer to do that *before* running a magical script. You might find it useful to manually posterise an image very slightly before optimisation, as this can lead to largeish gains with minimal quality loss (though this is essentially a crude version of one of the many terrifying things tinypng does, and it's probably better at it than we are).
nope I did not :) Thanks ckitching!
Thanks for all the details! Would you be interested in doing this for me here and in bug 1055657? I can definitely do it myself, but you would probably do it faster ;)
I just used pngcrush on the images. https://hg.mozilla.org/integration/fx-team/rev/a2a543711800
Status: ASSIGNED → RESOLVED
Closed: 5 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 36
(In reply to :Margaret Leibovic from comment #21) > I just used pngcrush on the images. > > https://hg.mozilla.org/integration/fx-team/rev/a2a543711800 Sorry for not getting back to you on this sooner. (In reply to :Margaret Leibovic from comment #20) > Thanks for all the details! Would you be interested in doing this for me > here and in bug 1055657? I can definitely do it myself, but you would > probably do it faster ;) Perhaps, but that solution doesn't scale :P. I'll do a handy blog post on the topic and provide the scripts I use to automate the process so everyone can do this exactly as fast as I can (and hopefully better if they ever figure out how to work around the weird partial-transparency problem)
Comment on attachment 8513908 [details] [diff] [review] Add images for search widget preview Approval Request Comment [Feature/regressing bug #]: search activity [User impact if declined]: search widget preview looks wrong [Describe test coverage new/current, TBPL]: no test coverage, baked on m-c [Risks and why]: low-risk, image swaps [String/UUID change made/needed]: none
Attachment #8513908 - Flags: approval-mozilla-aurora?
Attachment #8513908 - Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
I tested this with Asus Transformer TF101 (Android 4.0.3) on Firefox for Android 35 Beta 1 build 2, Firefox Beta Search widget preview looks good, so I will change the flag for status-firefox35 to verified. On Firefox for Android 36.0a2 (2014-12-04), Aurora search widget preview uses Nightly icon so I filled a new bug, Bug 1107485.
Aurora search widget preview uses Nightly icon, so I will mark status-firefox36 as verified based on comment 15.
Considering that Firefox 34 is released I will mark this as Verified fixed.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.