Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow the DrawImage overrides that need an ICanvasImage to specify destination rectangle #31

Closed
r2d2rigo opened this issue Nov 20, 2014 · 3 comments

Comments

@r2d2rigo
Copy link

I'm using the Win2D control for adding rich image effects to a Windows Phone application. Right now I'm using a GaussianBlurEffect to animate the transition between two images, but I have found that the DrawImage overrides that let me use the output of an effect (those that accept an ICanvasImage instead of a CanvasBitmap) don't have any way of specifying a destination rectangle.

Is this feature going to be considered or should I use another approach (intermediate render target, draw to bitmap, etc.)?

@shawnhar
Copy link
Member

Hi Rodrigo,

The reason we do not provide those overloads is that the source size of an arbitrary image is not well defined. For bitmaps it makes total sense to say "take this bitmap and draw it into this rectangle, scaling however needed to make it fit", because the source size of the bitmap is simple and obvious so we can work out the necessary scaling factor by comparing source and dest sizes. But for an arbitrary effect this approach falls over:

  • Some effects are infinite in size
  • Some effects have sizes that are likely to be surprising and not do what people want
  • For complex effect graphs the size can be expensive to compute, so we don't want to provide APIs that have to do this all the time and would make it look cheaper/simpler than the work really is

An example of something that seems simple, but doesn't actually work right if the API depended on effect source size is exactly what you're trying to do, take a bitmap and blur it. You start with the bitmap being scaled to fit in a rect, which is well and good. Now you feed that bitmap into a blur effect, and scale the blur to fit the rect. But the size of the blur is slightly larger than the original bitmap, due to the softening of its edges! So the total image shrinks slightly as soon as the blur is turned on. The more you increase the blur radius, the more it shrinks. This would be very odd and almost certainly not what anybody actually wanted :-)

These problems do not occur when positioning effects at a point instead of by target rect. You can draw a bitmap at a point, then switch to drawing a blurred version of that bitmap, and the image stays in the same place, just getting blurrier. As you increase the blur radius, the bounds of the effect actually go negative relative to the origin, so it can draw blurred pixels above and to the left of the original bitmap, and everything works out in the logical way.

There's no need for an intermediate rendertarget here, though - you can use a Transform2DEffect to apply whatever scaling is needed to your image.

@r2d2rigo
Copy link
Author

Oh wow @shawnhar, thank you very much for such a detailed explanation! I would be more than happy with just 2-3 lines saying that it's not feasible but you went the extra mile :)

I started noticing something weird when I added animation to the blur amount of the effect, but didn't know that it was due to the image bounds being reduced as you said. I fixed it by getting the bounds of the effect's output to calculate a transform that was set in the CanvasDrawingSession.Transform property. However, from now on I will feed the output of a Transform2DEffect that properly up- or down-scales the image to the GaussianBlurEffect, and draw the result directly.

I'm closing this issue with this response. Keep up the good work!

@Postlagerkarte
Copy link

That was an excellent explanation! You should move stuff like this into a blog post or to a faq section ;=)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants