#6986: Media Processing Html Filter (improved)

[BenedekFarkas]

Fixes #6986

Originally developed by @anoordende from @zumeymedia in #6992.

Original description

Enabling this feature registers an implementation of IHtmlFilter that works on any part with a flavor of "HTML" that injects and applies the registered IHtmlFilters.

Additional settings appear under in the Admin UI under Settings > Media to control to behavior of this feature. It is quite straightforward:

Density Threshold
With a threshold of, for example, @2x, an image will only be reduced if the natural size of the image is more than 2x the size specified in the attributes.

Quality
Only applies to jpeg's, the quality to compress the image at.

Populate Empty Alt Tags
If the img has an empty Alt tag, one will be composed based on the image file name

noresize attribute
Adding a noresize attribute to any img element will cause the element not to be processed:

<img noresize src="/Media/example.jpg" alt="this image will not be processed" />

_Note that images already the result of a profile (ie already under /Profiles/*) will not be processed.

To try out this feature, simply add a suitable image from your media library to e.g. a body part and use the handles in the editor the resize the image. When rendered, you will see that the image comes from a profile and not from the original source. Change the quality or density in the settings and you will see new profiles being generated.

Clean up the dynamic test profiles or force regeneration with the "Purge Obsolete" feature from PR #6984.

[BenedekFarkas]

@sebastienros re: #6992 (comment)

I would not use HtmlAgilityPack. It seems too heavy for the goal here, probably a compiled Regex or a custom parser would be able to fetch all images. Just thinking about performance here.

I just tested and slightly updated it. I can't speak to the performance impact, but it would be nice not to have this contribution go to waste and it's an optional feature anyway.

On the other hand, if substituting HtmlAgilityPack with regexes is not too complicated, then I'm down to avoid adding a new(-ish) dependency. New-ish, because Orchard.Azure.MediaServices uses it too, but that will be removed and Orchard.Specs as well, but that's not part of the application when deployed.

[BenedekFarkas]

@sebastienros please check again - based on our discussion last Thursday it now uses regexes and StringBuilder (without HtmlAgilityPack at all).

[BenedekFarkas]

@sebastienros added the caching steps according to your comments. I did a stress test that renders the same image in 12 different sizes 200 times (= a total of 2400 images rendered) and HtmlAgilityPack is only 20-30ms slower while the total page load was always between 800 and 900 ms. It seems that HtmlAgilityPack was pretty efficient already, so that's nice to know.