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.
_______________________________________________ wayland-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/wayland-devel
