gl-renderer: Take into account viewport when choosing filtering

Currently the viewport isn't taken into account when choosing filtering - we end up with GL_NEAREST filtering when we should have GL_LINEAR. Take into account the viewport when choosing filtering to solve this issue.

Fixes: #554

Signed-off-by: Christopher Obbard chris.obbard@collabora.com

changed the description

So, the MR is good in that it fixes a problem (clients which use viewporter to scale should definitely get HiDPI). On the other hand it also disregards any cumulative transform effects so might have a slight regression in terms of over-aggressively enabling non-nearest filtering.

I'd like to see this replaced longer-term by having the total transform encoded into the paint node directly, so we can just look at that rather than trying to open-code all the different checks into a million different places.

So I'm not really sure if we want to merge this for now or just leave it. Thoughts?

I'm definitely going to vote in favour of leaving it, because the transforms are really unpleasant to deal with, and this only makes it worse.

For me, the best path forward would be:

• for each co-ordinate space (buffer, surface, view, global, output), add an encapsulating weston_${i}_{coord,area,region} type which is a dumb wrapper around two/four/n points
• for each step in the above, define intermediate (e.g. buffer<->surface, surface<->view, etc) conversion functions which actually take everything into account
• start demolishing the number of open-coded conversions we have throughout the tree (which will be obvious as they'll fail to compile)
• as part of this, implement it in such a way that the cumulative transform can also be obtained
• inspect the cumulative output -> global -> view -> surface -> buffer transform and determine the scaling that way

added GL renderer label

added Needs rework label

As of !1015 (merged) we should properly choose filtering based on the cumulative transform of the buffer to output matrix.

I'm going to close this MR now.

I completely forgot about this and it's not relevant for my work anymore, so I won't be able to work on this in future. Are you saying there is nothing left to do here ? If not, should we create an issue ?

Should be nothing left to do. The viewport's transform should be accounted for in the matrix math we now use for the filtering decision.

Thanks! Was just wondering if this is considered done or not.

closed