[PATCH weston 0/8] wl_viewport enhancements

[Bill Spitzak]

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 
position.

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.