Strange behaviour

General JUCE discussion
1

Hi Jules,

Let’s say I have a 640x480 window and a 1280x960 image.
If I write this code in Paint,

	g.drawImage(destImage, 0, 0, getWidth(), getHeight(), (int)XOffset, (int)YOffset, (int)(getWidth() / zoomFactor), (int)(getHeight() / zoomFactor), false);

with XOffset and YOffset modified in mouseDrag simply by adding +1, -1
and zoomFactor a float value (usually 1.0f).
this works when zoomFactor is 1.0f (as expected) and draw a 640x480 image from a 640x480 window of the destImage with (XOffset, YOffset) origin.

However, if the zoomFactor become 2.0f (for example), I would expect the drawImage to still draw a 640x480 window from a 320x240 window of the destImage with (XOffset, YOffset) origin.

With the current code, all I have is a shifted (translated) and zoomed picture, not a zoomed picture.

2

Hmm - yes, looks like I got my affine transforms in a bit of a twist - juce_LowLevelGraphicsSoftwareRenderer.cpp, line 1742 should be:

if (sw == dw && sh == dh) { blendImage (sourceImage, dx, dy, dw, dh, sx, sy, alpha); } else { blendImageWarping (sourceImage, sx, sy, sw, sh, AffineTransform::translation ((float) (dx - sx), (float) (dy - sy)) .scaled (dw / (float) sw, dh / (float) sh), alpha, quality); }

There’s also an issue when the source rectangle goes beyond the image’s bounds, which needs a few changes to fix - too many to post here.

To avoid all these problems in the meantime, you could just use Graphics::drawImageTransformed to draw it instead, and that should work ok.

3

Well, it doesn’t work like said but translation with sx-dx, sy - dy worked.

It is a little bit slow for the picture size I’m using, but yes, this is a workaround.

4

[quote=“X-Ryl669”]Well, it doesn’t work like said but translation with sx-dx, sy - dy worked.

It is a little bit slow for the picture size I’m using, but yes, this is a workaround.[/quote]

I’m 99% sure that (dx - sx) is correct - are you sure it’s not your own code that’s got its value the wrong way round?

5

I don’t know exactly. Previously, I used drawImage like above, but with drawImageTransformed, I must use -XOffset and -YOffset in the translation part (to get the same effect)

My case is a specific case (because sx = sy = 0), but if I want to draw the area (10, 15) -> (330, 255) of a 640x480 picture to (0,0)-(640x480), I guess the translation should be -10, -15, ie -dx, -dy.

Either drawImage is inconsistent, either the transform is inverted compared to my logic.

6

(10, 15) is the source, not the dest, so (-10, -15) is (-sx, -sy). Transforms can be quite confusing…

7

Ok I got it

8

FYI, I just noticed that my fix here wasn’t quite right if there was some rescaling going on. Third time lucky:

blendImageWarping (sourceImage, sx, sy, sw, sh, AffineTransform::translation ((float) -sx, (float) -sy) .scaled (dw / (float) sw, dh / (float) sh) .translated ((float) dx, (float) dy), alpha, quality);

9

So there’s a new release soon ?

I’m not using this anymore (because it’s to slow), but it seems more right now.

10

New release will be soonish. I’ve a couple of things to add first. Probably do one early next week.