diff options
| author | Søren Sandmann Pedersen <ssp@redhat.com> | 2012-03-28 22:47:34 -0400 |
|---|---|---|
| committer | Søren Sandmann Pedersen <ssp@redhat.com> | 2013-07-29 06:21:51 -0400 |
| commit | 51ebfbde91e7cb4432a7b7a7daca83bb87967e5e (patch) | |
| tree | bccb510f437bed5ab87aa48a2074fb5b23f8fe80 | |
| parent | d260da62a9f2bba2c7dab615583b206229affd77 (diff) | |
sampling
| -rw-r--r-- | docs/resampling | 10 |
1 files changed, 9 insertions, 1 deletions
diff --git a/docs/resampling b/docs/resampling index 8fa97b5d..fa65b989 100644 --- a/docs/resampling +++ b/docs/resampling @@ -87,7 +87,15 @@ sampling, and pixman decides to supersample? This will look ugly. The answer may be that if pixman can't reasonably support the *combination* of interpolation and resampling filter, it will fall back to GOOD. However, this would complicate the query that X would -have to respond to. +have to respond to. Maybe it's not a problem since in the dirac case +we *can* actually do something reasonable, even though in the box +filter case the result will be awful. Ie., + + for a given image type, some interpolation and resampling + filters may not be supported, but if a particular interpolation + filter is supported, it is supported in combination with all + resampling filtersz. And vice versa. Ie., no rejecting of + specific combinations. It doesn't bother me that users have to understand signal processing concepts like dirac deltas or lanczos filters, but it would bother me |