Add wallpaper thumbnail assets
Categories
(Firefox :: New Tab Page, enhancement)
Tracking
()
Tracking | Status | |
---|---|---|
firefox126 | --- | fixed |
People
(Reporter: amy, Assigned: amy)
References
(Blocks 1 open bug)
Details
(Whiteboard: [hnt])
Attachments
(2 files)
For the initial experiment, we will add wallpaper image assets to mozilla-central. The wallpaper a user selects will be referenced by a local user pref (see bug 1881585).
Assignee | ||
Updated•8 months ago
|
Updated•8 months ago
|
Assignee | ||
Comment 1•8 months ago
|
||
Hi Mike! Do you foresee any performance issues with us storing wallpaper images in-tree for now? In the future we will explore serving these with remote settings, but we want to ship an initial experiment/proof of concept.
Assignee | ||
Comment 2•8 months ago
|
||
^ the needinfo was not posted for comment 1. ^^;
Comment 3•8 months ago
|
||
Storing the images in tree? No, I don't necessarily foresee a performance impact there. What we have to be a little wary of is reading from those files early during startup. The larger those wallpapers are, and the slower the user's disk / CPU is, the longer they'll take to render the initial about:home. Presuming these wallpapers are binary images, it might be worth talking to the Graphics team to see what image format best matches our constraints. aosmond would be my first choice of person to talk to there.
Assignee | ||
Comment 4•8 months ago
•
|
||
Hi Andrew! We are doing an initial experiment/proof of concept for adding background images to the new tab page (wallpapers). For the first phase, we will be storing images in-tree before exploring importing these images remotely. Do you have a recommendation for image format or size constraints?
Assignee | ||
Comment 5•8 months ago
|
||
Hello Markus! For our new tab wallpapers experiment, we are initially planning to add wallpaper image assets in-tree (UX proposes 12 images total.) Once we graduate the experiment we will remove these and explore importing images with remote settings. Do you have a recommendation for image format or size constraints?
Comment 7•8 months ago
•
|
||
Hi, thanks for reaching out! These are the metrics we should keep in mind (there might be more, but these are the ones I can think of):
- Firefox bundle download size
- Firefox memory usage
- Firefox startup time
- New tab page paint time
The preloaded new tab page probably solves 4 at the cost of 2. For 3, when developing this feature, please make sure to do profiling with IO markers and check whether the images are read from disk during a time when other startup-critical work is happening, and if so, delay the loading.
(In reply to Amy Churchwell [:amy] from comment #5)
Do you have a recommendation for image format or size constraints?
The image format might not make much of a difference. WebP probably gives you slightly smaller images than JPEG at the cost of slightly slower decoding. I'd recommend just trying it and comparing the results. For Firefox memory usage, the compressed size doesn't make a difference because Firefox keeps the decoded version in memory as long as it's visible somewhere, and the decoded byte size is always width x height x 4.
(In reply to Amy Churchwell [:amy] from comment #5)
Once we graduate the experiment we will remove these and explore importing images with remote settings.
So would these wallpapers be part of the download, even in Firefox Release? Or would the experiment be Nightly-only? It would be unfortunate to make the release download bigger for an experiment.
Comment 8•8 months ago
|
||
(In reply to Jeff Muizelaar [:jrmuizel] from comment #6)
Can you attach the images to the bug?
This is the drive where all images are, both in AVIF and in WEBP
https://drive.google.com/drive/folders/1vIBvT63sB7IilK1yQpUMqYwwDQCvb4VQ?usp=sharing
Assignee | ||
Comment 9•8 months ago
|
||
(In reply to Markus Stange [:mstange] from comment #7)
So would these wallpapers be part of the download, even in Firefox Release? Or would the experiment be Nightly-only? It would be unfortunate to make the release download bigger for an experiment.
Experiments are only ran in release, so they would. Tati commented with the images we plan on using in two different formats we can choose from. If those are deemed too large to land we can also explore using remote settings to serve the images, which we were planning on doing after we graduate the experiment. Thank you for the feedback!
Comment 10•8 months ago
|
||
Thanks! So the total size of the 12 WebP images is 743KB, which is actually less then I expected. I'm going to ask around in the performance team what our opinions on download size increases are. It looks like the download size has increased by 7MB over the last 12 months (87MB -> 94MB, which isn't all that great.
Have you considered just serving the images at some URL and just using that URL directly on the new tab page? Then you'd be at the mercy of our network cache, but it still might work quite well.
Comment 11•8 months ago
|
||
Hey Markus - We'll be adding these images to the RemoteSettings API and if participating in the experiment - the call to RemoteSettings would download the images (as a blob) to the local indexedDB, rather than adding them to tree and increasing the download size. Let me know if you have any question / clarification on our approach
Comment 12•8 months ago
|
||
Sounds good! I appreciate it.
I haven't heard any opinions on download size in the perf team, it might be more a question for product. But with the RemoteSettings approach we don't even need to have that conversation, excellent.
Assignee | ||
Comment 13•8 months ago
|
||
While we will be serving the background images with remote settings, we will be adding smaller assets for the thumbnail images. Which this bug will be used for.
Assignee | ||
Updated•8 months ago
|
Assignee | ||
Updated•8 months ago
|
Assignee | ||
Comment 14•8 months ago
|
||
Comment 15•7 months ago
|
||
Comment 16•7 months ago
|
||
bugherder |
Comment 17•5 months ago
|
||
I would say AVIF, JPEG and PNG are all pretty good depending on your use case and transparency needs. I don't necessarily have any recommendations on the resolutions. Our telemetry report has a break down of the typical display sizes for our users, 1920x1080 and 1366x768 resolution being the most popular respectively:
https://data.firefox.com/dashboard/hardware
I would say depending on how high resolution this is and what artifacting you might see from stretching, it would be quite reasonable to supply a high def and lower resolution versions. I think there is precedence for that elsewhere in the stack. Note that we do high quality downscaling in general, so it should look pretty good if it is downscaled (it just is more expensive to decode). Upscaling is where you would tend to see more artifacting, if any.
Description
•