[PATCH weston 0/8] wl_viewport enhancements
spitzak at gmail.com
Thu Mar 20 11:58:11 PDT 2014
Pekka Paalanen wrote:
> The sampling really goes into hair-splitting. It depends on how you
> interpret a texel image; is each pixel a solid-colored tile, or does
> the color vary smoothly from texel to the next. Then you have the
> source rectangle, which is divided into dst_width x dst_height pixels
> (let's assume output_scale=1). For each pixel, do you take a point
> sample from its middle, or do you integrate an average over the pixel's
> area in the source texture. In any case, I see that point sampling is
> well-defined always, and a theoretical prerequisite for the integration
> since we can and will sample "between texels". In that respect, a 0x0
> source rectangle would just mean that all pixels will be point samples
> at src_x,src_y.
I see the source image as being solid-colored tiles for the pixels, but
accessing a value from it involves integrating the product of these
tiles with a "sampling filter". Actual implementations convert the
continuous filter to a weight for each pixel's color, note that these
weights depend on the fractional part of the sample position.
The bilinear interpolation that I believe you are considering is
equivalent to making the filter a 1x1 square centered on the sample
This interpretation is necessary to produce correct sampling when an
image is scaled down. The filter is then bigger than 1x1. This cannot be
done with a point-sampled continuous source unless that source varies
depending on the scale, an approach which I find much harder to deal
with than sampling filters.
It also makes it possible to do more complex filters such as sync
filters. For continous filters with a frequency of 1/2 or less (such as
the sync at scales <= 1) it is accurate to use the value of the filter
at the center of each pixel as the weight for that pixel.
Normally when scaling *up* the filter does not get smaller, it stops at
the same size it is at scale=1. This is what bilinear interpolation
does. However this scheme can well-define a scaling up that lets the
user see pixels as blocks but with anti-aliased edges. This can be done
with a filter that is smaller than 1x1. There is some desire for this
behavior, for instance OS/X does it by default.
> So, better forget that and do what seems natural. The minimum sampling
> area (source rect) will be 1/256 x 1/256 texels per surface pixel,
> then. Output_scale would make that respectively smaller, too.
Okay I was unaware that the source did not align with pixels. I thought
the reason you were using fixed-point is to allow it to be aligned with
pixels even if buffer scale is not 1.
As I saw it the scaling was expected to transform the center of each
output pixel to a location in the input and center a filter there. If
you assume you are scaling up and a 1x1 box filter is used, the center
of the samples will never be closer than .5 to the edge of the source
rectangle and thus the filtering will never multiply any point outside
the source rectangle by non-zero.
This assumption is false if the box is allowed to be smaller than 1x1.
It is also somewhat false if the box does not align with pixels (the
filter is still inside, but when translated to weights at pixel centers
it puts a non-zero weight outside the box.
The filter also goes outside if there is scaling down instead of up, or
if a more complex filter than a box is used. I was under the impression
that an implementation was either required, or at least allowed, to
clamp the filter locations to be inside the box. It now sounds like the
box should be ignored except to calculate a scale+translate that should
be done, followed by a crop to the destination rectangle.
>> As far as negative size -> disable goes, I like it. We need some way of
>> disabling them, and that works fine. You could make an argument about how
>> we should send an actual error and kill the client, but I think just
>> turning off crop-and-scale is sufficient.
Yes I'm ok with negative meaning disable. I was just recommending that
zero *also* mean disable.
More information about the wayland-devel