diff options
| author | Søren Sandmann Pedersen <ssp@redhat.com> | 2010-07-21 19:33:36 -0400 |
|---|---|---|
| committer | Søren Sandmann Pedersen <ssp@redhat.com> | 2013-07-29 06:21:49 -0400 |
| commit | 801e64ab89274f535929ead16ab185628badf9d5 (patch) | |
| tree | d7ab1373aacecba9e32b9f02675bdbeb78b6f08e | |
| parent | e9c27b94816b4968d55ef2957c525ce2358fd958 (diff) | |
transform
| -rw-r--r-- | docs/transform-bounds | 10 |
1 files changed, 7 insertions, 3 deletions
diff --git a/docs/transform-bounds b/docs/transform-bounds index b99fc9e3..57bb44e9 100644 --- a/docs/transform-bounds +++ b/docs/transform-bounds @@ -5,7 +5,7 @@ If we look at the two issues separately: precision. The main difference is that transform_bounds() is transforming the -bounding of the clip in destination space: +bounding box of the clip in destination space: +---+---+---+---+--- | x | x | x | x | x @@ -34,8 +34,12 @@ So basically, this function can't actually do its job very well without knowing what filter is being used. What is its job anyway? I think the reasonable description of that -function is that it returns a conservative estimate - +function is that it returns a conservative estimate of the area of the +shape that a box is transformed into. That is also the correct +computation if you use a NEAREST filter. However, there is one problem +currently: if the transformed box ends up exactly at an integer +boundary, then it won't include the pixel just before. Ie., we need to +subtract epsilon for that to be true. coordinates |