API review request: ImageView.viewport behavior

[Jim Graham]

Note that we have a deadline coming up very soon, so feedback is 
critical (and the same to be said for the Image Ops proposal)...

			...jim

On 5/14/2012 3:25 AM, Jim Graham wrote:
> We have these two requests to clarify and fix the behavior of the
> viewport on an ImageView. They don't involve any new API, just questions
> and suggestions on changing the behavior of the existing property:
>
> http://javafx-jira.kenai.com/browse/RT-19962
> http://javafx-jira.kenai.com/browse/RT-19306
>
> The history of this bug is that the code to implement viewports was
> ported from the Java2D source base where it had an integer "draw sub
> image" method. The 2D method interpreted the subimage parameters as
> defining a piece of the image "a subimage" that behaved as if it were
> extracted and isolated and then rendered as its own image.
>
> The FX implementation uses floating point values to define the viewport
> and describes it merely as defining "the portion of the image which
> falls within the viewport [is] displayed" and elsewhere as achieving a
> "zoom effect" if you narrow the viewport without narrowing the fit
> dimensions.
>
> The distinction of whether the viewport/subimage is considered in
> isolation only matters if you are using image smoothing, which is on by
> default in FX and off by default in AWT. If you are smoothing, then
> special math is used for the border pixels because they have no adjacent
> pixels to smooth against.
>
> In 1.3 and 2.0 the math was broken in the FX version because it was
> ported over from the 2D version which had a different rendering model.
> We fixed the bugs in 2.1 and brought it into compliance with "what it
> seemed to be trying to do" which was to isolate the image defined by the
> viewport.
>
> The problem was, when we "fixed those bugs" we realized that there
> wasn't really any good definition of what the "subimage" was when you
> are using floating point coordinates since it is hard to create an image
> from fractions of the border pixels.
>
> So, we filed the above bugs to clarify this and to change the
> implementation of viewports to be more like what you get with "texture
> mapping" where they simply define the points on the image that map to
> the corners of the ImageView's output.
>
> If there are no objections, I'd like to remove the synthetic "edge
> conditions" on the ImageView viewport so that it simply acts like a clip
> affecting what is seen from the original image - a sort of "narrowing
> lens" if you will...
>
> ...jim