New g.drawImage () bug?


#1

Hi,

I was using g.drawimage () for custom look& fill of knob from png film strip.
i.e. my image try to pain a portion of it only like
g.drawImage (image,0, 0,oneFrameWidth,oneFrameHeight, 0, 0, oneFrameWidth, oneFrameHeight);

But since a few tips, it’s all broken and it’s looks stretched and misplaced.
reverting a few tips back fix it.

Anyone else ?

Salvator


#2

Thanks, yes - looks like a bug in my new CoreGraphics code. Will get it sorted right away…


#3

Works,
Better and faster than fastfood !
:mrgreen:
Salvator


#4

This seems to still be an issue. I’m sure your aware and working on it … but just in case it’s useful, I notice that:

Using drawImageAt I get the image properly … the image is 500x500, but using drawImage, I get only a very small corner of the upper right part of the image. Going back a few revisions clears it up.

g.drawImage(captureImageProcessed, 0 , 0, 500 , 500 , 0, 0, 500, 500, false);

g.drawImageAt(captureImageProcessed, 0 , 0, false);

Also … if I replace the 500s with 5000s I get something like the whole image. Could it be that the viewing rectangle is getting scaled incorrectly somewhere?


#5

…nope, there’s no bug there. Are you using the latest tip?


#6

No, I’m using the tip, just downloaded tonight to make sure I was uptodate. Here is a clearer demonstration of the issue …

g.drawImage(captureImageProcessed, 0,0, 1600, 1600, 0, 0, 1600, 1600, false);
works …

g.drawImage(captureImageProcessed, 0,0, 1500, 1600, 0, 0, 1600, 1600, false);
works … rescaling the image

g.drawImage(captureImageProcessed, 0,0, 1600, 1600, 0, 0, 1500, 1600, false);
just blank, no image drawn.

g.drawImage(captureImageProcessed, 0,0, 1600, 1600, 10, 0, 1600, 1600, false);
also blank.

As you can see … I can change the destination x,y,w,h no problem … but any values for the source x,y,w,h other than 0,0, width(), height() … and I just get blank canvas. I’ve tried it with captureImageProcessed()->getWidth() - 100 and it also breaks.

The image is ARGB, not that it matters I suppose.


#7

Are those co-ords actually valid? The source rectangle must lie completely inside the image’s bounds or it should fail (and should throw an assertion - maybe you’re just not seeing that?). But there’s an optimisation that checks whether the dest and source are the same size, and if so uses a faster renderer, so that might just be incorrectly working in the first example, when it really ought to be failing.


#8

Yeah, I had thought that too … it’s definitely not the case though (the bounding box is definitely legal). This error is fairly new, and I noticed it because it broke my app in several places.

Also, taking a closer look … it’s not actually painting nothing: instead, it just paints the top 20 pixels or so … seems odd, so I checked it on several images to make sure I was getting consistent results. I always get just the top strip of the image.

Here is another example:

using drawImageAt or using the following code works as expected:
g.drawImage(beatImage, 10 , 40, 180, 50, 0,0, 180, 50, false); // (the image is 180x50 of course)

but reducing the bounding box:
g.drawImage(beatImage, 10 , 40, 180, 50, 0,0, 170, 50, false); // paints just the top 20 or so pixels … see attachment

Really confused on what’s happening here … so just kicking more grief your way I suppose.

PS - Tinkering with the rectangle in drawImageTransformed has the same effect:
g.drawImageTransformed (captureImageProcessed, Rectangle (0, 0, 170, 50),
AffineTransform::scale ((float)1, (float)1)
.translated ((float)0, (float)0), false);


#9

I tested this myself and it all seemed to be working just fine…


#10

ok, I believe it, thanks. I’ll drop a line when I figure out whats going on over here.


#11

If you can send me an image + test code I’ll have another go. I might just not be doing exactly the same thing.


#12