RFE: Support 8 argument drawImage method

[ddyer0]

When drawing images using a rotated graphics, the edge pixels are rendered incorrectly, apparently
due to the underlying sampling algorithm. I'll attach an image with a sample. This occurs across
all platforms, it's apparently just a hole in java's rendering algorithm. This is mainly a problem when
the images in question are transparent at the edges, so the expectation is that the edges do not draw.

In the un-rotated case, I paper over this problem by clipping the destination so the dirty pixels are
outside the clipping region. If the image is to be drawn rotated, this is not possible. On java desktops,
I avoid problems in the rotated case by drawing a region inside the source image (normally by 1 pixel)
so there is a real pixel outside the intended source which can be sampled.

The correct solution to this problem would be if the graphics engine provided a user-specified value
to be used for nonexistant pixels the sampling algorithm tries to sample. Short of that, codename1
could support the "8 argument" version of drawImage that regular java includes.

public void drawImage(Image im0,
		int dx,int dy,int dx2,int dy2,
		int fx,int fy,int fx2,int fy2)

[shai-almog]

If this occurs across all platforms it's very likely an issue in your code. The rendering pipelines are vastly different between the various platforms. I'm closing the issue since no standalone clean test case was provided.

[ddyer0]

look at the picture, it's just a rotated piece and the invisible boundary is clearly visible.
In any case, the ask is to supply the 8 arg drawImage

[shai-almog]

I converted the issue to an RFE, right now I'm leaving it unassigned since this is a big task. The work required should be done on all pipelines and that's difficult. If there's wide demand we'll consider that. But at the moment there are other priorities.

[ddyer0]

Thanks. I think this is a hole in the basic graphics model and using the 8 arg drawImage is the correct solution within the model.