We fixed the implementation of viewports in the presence of scaling and fit-dimensions in 2.1 to match what the code appeared to be trying to do, but in doing so it raised questions as to whether that behavior was really desirable.

Specifically, the code appears to simulate what the image would look like if you extracted the pixels into a separate, smaller, cropped image and then did its standard rendering from that cropped version. The primary visual effect of that theoretical procedure would be that the outer 0.5 pixels of the source image are clamped to the value of the pixels on the edge rather than blended to transparency or blended with the next pixel over in the whole image.

That behavior matches what Java2D does, but Java2D had only integer values for the subpixel coordinates so the concept of "pretending the image only had the pixels that appear in the defined subimage" made more sense. Unfortunately, the FX ImageView object has floating point coordinates for its viewport so it begs the question - what does it mean to extract the image that consists only of "these pixels plus this fraction of those pixels" when the floating point viewport coordinates are not integers? In fact, the ImageView's viewport parameters seem more similar to the concept of 3D texture mapping which does not simulate "edge conditions" for the edges of the texture coordinates when they represent a sub-image.

Finally, with floating point coordinates for the subimage, the operation seems more similar to the HTML5 drawImage() method that takes a set of source rectangle coordinates (in floating point). We should look at what that API defines for subimages and consider that that behavior is already locked into the expectations of our target developers.

Once we decide what the behavior that we actually want is, it should be a simple matter of implementing the new behavior, but we need to investigate HTML5 and create a demo app that shows the differences so our API designers can make a decision...