Resolution awareness when loading images

[Kris Giesing]

Hi folks,

I've just landed a few patches that allow Flutter to load images of a resolution appropriate to the current device pixel ratio.

AssetImage now understands how to map a logical requested asset onto one that most closely matches the current device pixel ratio. In order for this mapping to work, assets should be arranged according to a particular directory structure:

.../image.png

.../Mx/image.png

.../Nx/image.png

...etc.

where M and N are numeric identifiers that correspond to the nominal resolution of the images contained within. The main asset is assumed to correspond to a resolution of 1.0. For example, consider the following asset layout for an image named "my_icon.png":

.../my_icon.png

.../2.0x/my_icon.png

.../3.0x/my_icon.png

On devices with a device pixel ratio of 1.8, the asset ".../2.0x/my_icon.png" would be chosen. For a device pixel ratio of 2.7, the asset ".../3.0x/my_icon.png" would be chosen.

If the width and height of the rendered image are not specified, the nominal resolution is used to scale the asset so that it will occupy the same amount of screen space as the main asset would have, just with a higher resolution. That is, if ".../my_icon.png" is 72px by 72px, then ".../3.0x/my_icon.png" should be 216px by 216px; but they both will render into 72px by 72px (in logical pixels) if width and height are not specified.

The way this works is through an object called AssetVendor established at the top of the build tree.  AssetVendor replaces the default asset bundle, so really anything using the default asset bundle will inherit resolution awareness when loading images.  If you work with some of the lower level classes, like ImageResource or ImageCache, you'll also notice some new parameters related to scale.

Some caveats:

- If you're not using MaterialApp in your application, and you want to use resolution awareness, you'll need to establish your own AssetVendor in your build logic.

- If for some reason you establish a custom MediaQuery or DefaultAssetBundle farther down in the widget hierarchy, the top-level AssetVendor won't be aware of the change.  If you want resolution awareness with the new MediaQuery or DefaultAssetBundle you specify, you'll need to create an AssetVendor at that point in the tree as well.

Please don't hesitate to bring up any issues or concerns with the new feature.

Happy fluttering,

- Kris

[Seth Ladd]

Super cool! Is there an example/demo in the repo where we can see this in action?

--
You received this message because you are subscribed to the Google Groups "Flutter Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to flutter-dev...@googlegroups.com.
To post to this group, send email to flutt...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/flutter-dev/CANW_4OZk2%2B%2Bdtbq%3De_DBemi%3DCUsXNacA_K7SJWZD8AB36nvyfg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[Kris Giesing]

Yes, there's a new example under examples/widgets:

flutter start -t resolution_awareness.dart

The example is a bit artificial in that it inflates the images so that the difference in resolution is more dramatic - in normal use, the differences between resolutions are a little harder to see without squinting :)

- Kris

[Josh Estelle]

Related question:  is there / will there be any support for vector graphics in Flutter?

To view this discussion on the web visit https://groups.google.com/d/msgid/flutter-dev/CANW_4OYTaWZTF2Go9zm6UpS%2B%2BNy0YLhMcSQvUu8TBrj7%3DrUx3g%40mail.gmail.com.

[Eric Seidel]

There is currently no direct support for such. I anticipate we will
need some kind of resolution-independent graphics support, but
hopefully offered as an optional service instead of baked into the
core engine (like svg on the web) which everyone pays binary/memory
cost for having.

One could even write a small amount of dart code to support SVG
parsing and static SVG 1.2 rendering on top of our existing 2d drawing
APIs. Such would be pretty straightforward (I've done such before in
other languages). PDF is a whole 'nother ball o' (crazy) wax. Not
sure if there are other popular vector formats on mobile.

On Tue, Feb 2, 2016 at 4:51 PM, 'Josh Estelle' via Flutter Dev

> https://groups.google.com/d/msgid/flutter-dev/CAOQMEmhK8KAJMPTpGADNLY8kP7JTgbe-i2AGxHxtuHpbQmzUAw%40mail.gmail.com.

[Ian Hickson]

Technically we really only support vector graphics (our graphics pipeline is based on OpenGL calls, not pixels), but as Eric says we don't have an exposed serialisation format yet to display vector images from the network (or disk). I recommend filing bugs if there are specific formats that you think should be supported. We probably wouldn't want to implement formats that are intrinsically low-performing or absurdly complicated (like full dynamic SVG or PDF), but if there are efficient formats that would definitely be a good place to start. It would be reasonably straight forward to invent a custom format that just matched our API, too.

To view this discussion on the web visit https://groups.google.com/d/msgid/flutter-dev/CA%2Bbb4fn7xhTuVFPs8JvP3kvXtH6rEWqpE%2BfX0PxwH-BUmiPJCg%40mail.gmail.com.