In the GDI+ pipeline, the source image is loaded very early... ImageBuilder.LoadImage() is called at the top of ImageBuilder.BuildJob(). We might be able to co-opt AbstractImageProcessor.PreLoadImage(), but the obvious place to stash the watermark images, ImageState.Data, doesn't exist yet. (It doesn't get created until ImageBuilder.buildToBitmap().)

Rather than using ImageState.Data, or changing the signature for PreLoadImage(), the watermark plugin itself could cache the watermark images, which might also allow them to stay in memory across multiple ImageBuilder.Process() calls. Does that seem reasonable? I'm starting with this as the design, but wanted to bounce the idea off of you in case there were specific multi-threading/contention issues that would need to be worked around, or if there is a better place to stash the watermark images between load and render.

It looks like watermark Bitmaps are already getting cached by the ASP.NET cache, when it's available. Can we simply rely on this for the pre-fetch as well? We can call GetMemCachedBitmap() purely for the side-effect of ensuring the image is in the cache before the Render call.

I'm not sure in what cases HttpContext.Current would be null in practice, but leveraging GetMemCachedBitmap() would be much simpler than adding caching to ImageLayer or the Watermark plugin itself, and automatically handles aging out cached watermarks after a period of time.

Yes, that's fine - we're already making the assumption that watermarks remain in memory - this would just make that usage more effective. In a later version I'd prefer to cache only the bytestream or immutable decoded bitmap, but this is easier for now.