Bug 69231 - add 512x512 to the lookup
Summary: add 512x512 to the lookup
Status: RESOLVED FIXED
Alias: None
Product: Icon theme
Classification: Unclassified
Component: hicolor (show other bugs)
Version: ALL
Hardware: Other All
: medium normal
Assignee: Alexander Larsson
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-09-11 15:52 UTC by Jakub Steiner
Modified: 2013-12-17 10:31 UTC (History)
1 user (show)

See Also:
i915 platform:
i915 features:


Attachments
support 512x512 lookup (15.81 KB, patch)
2013-09-11 16:07 UTC, Jakub Steiner
Details | Splinter Review
don't change maxsize of scalables this time (14.78 KB, patch)
2013-10-11 14:46 UTC, Jakub Steiner
Details | Splinter Review

Description Jakub Steiner 2013-09-11 15:52:08 UTC
The current practice is to shiip highly detailed application icons at the 256x256px size. For the more and more common dnese displays such as the one found on the Chromebook Pixel, this may not be enough. 

We should add a 512x512 lookup size without breaking the existing 256x256 max size and scalable app icon shipments.
Comment 1 Jakub Steiner 2013-09-11 16:07:45 UTC
Created attachment 85645 [details] [review]
support 512x512 lookup
Comment 2 Alexander Larsson 2013-09-12 07:54:26 UTC
Changing scalable max from 256 to 512 does change what icons would be picked atm even if no 512 icons has been added yet. Why do we want to change that?
Comment 3 Jakub Steiner 2013-09-13 15:11:54 UTC
(In reply to comment #2)
> Changing scalable max from 256 to 512 does change what icons would be picked
> atm even if no 512 icons has been added yet. Why do we want to change that?

Myy understanding of MaxSize is that the icons would not get scaled up to 512 is requested, but would be padded with whitespace around MaxSize to fit. I believe if a legacy icon that provides scalables instead of highres, it should render into the 512x512 canvas.
Comment 4 Alexander Larsson 2013-09-16 10:07:27 UTC
> Myy understanding of MaxSize is that the icons would not get scaled up to 512 
> is requested, but would be padded with whitespace around MaxSize to fit. I 
> believe if a legacy icon that provides scalables instead of highres, it 
> should render into the 512x512 canvas.

This is not how Gtk+ currently handles things. Scalable directories are always  scaled to fit the requested size. Threshold directories are not scaled at all inside the min-max region, but scaled outside that.

Take for example these current dirs:

[256x256/actions]
MinSize=64
Size=256
MaxSize=256
Context=Actions
Type=Scalable

[scalable/actions]
MinSize=1
Size=128
MaxSize=256
Context=Actions
Type=Scalable

And then we want to add:

[512x512/actions]
MinSize=64
Size=512
MaxSize=512
Context=Actions
Type=Scalable

If we then *also* bump scalable to MaxSize 512, then (assuming no 512 icons yet) someone requesting an image at 356 pixels will get a perfect match for scalable/actions, but 256x256/actions will be off by 100 pixels, so it will chose the scalable one instead. 

If both the scalable and 256 dirs were bumped to 512 we would chose the 256 one as it has a Size that is closer. However, i don't see the need for this, even if we don't change MaxSize on scalable or 256 we will scale any of those to 512 if someone requests a 512 icon.
Comment 5 Jakub Steiner 2013-10-11 14:46:06 UTC
Created attachment 87454 [details] [review]
don't change maxsize of scalables this time
Comment 6 Alexander Larsson 2013-12-17 10:31:29 UTC
I put this in 0.13, but I'm having problems getting the release up.
For now it is at:
https://people.gnome.org/~alexl/hicolor/hicolor-icon-theme-0.13.tar.gz


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.