Windowscommunitytoolkit: ImageEx Placeholder caching

[hermitdave]

When using a placeholder with ImageEx, we should aim to cache the placeholder since by the very definition, these do not change very often.

Once this is in place, the consumers would then be able to call PreCacheAsync and load this in memory rathan having to read from disc each time.

[hermitdave]

having looked at the source again, we only cache images if they have http source, placeholders are likely to be relative Uri.. maybe this needs a discussion rather

[ScottIsAFool]

Aren't most placeholder images those that are stored in the appx anyway? Do they need caching?

[hermitdave]

I was thinking about the in-memory storage to prevent read from disc

[ScottIsAFool]

Is that really that much of an issue?

[hermitdave]

I'd say that's subjective depending upon the number of images being loaded with placeholders..

[ScottIsAFool]

Fair point.

[jurepurgar]

Or you can instruct devs to simply do something like this: https://gist.github.com/jurepurgar/91154c213bf907508438db09bf67e598, since usually there are just a few different placeholders.

[hermitdave]

that is probably simpler by a long margin

[jurepurgar]

Maybe we can add this to the sample app, to show how is it best to deal with placeholders for performance reasons.

[hermitdave]

good idea

[JohnnyWestlake]

Most users are probably already getting a basic form of in-memory placeholder caching supplied by the platform. If you straight bind a Uri to an ImageSource on a Image, or use BitmapImage.UriSource, the XAML platform automatically handles in-memory caching for you - so this should already be good as PlaceholderImage is a straight ImageSource binding.

(Ref: https://msdn.microsoft.com/en-gb/windows/uwp/debug-test-perf/optimize-animations-and-media#caching-optimizations )

[deltakosh]

Agree (This is the official @JohnnyWestlake 's day :))
I think we should not over engineer this .