[PATCH] pixman-backend: add support for zooming
derekf at osg.samsung.com
Mon Sep 1 08:33:25 PDT 2014
On 01/09/14 04:52 AM, Jason Ekstrand wrote:
> On Mon, Sep 1, 2014 at 2:37 AM, Pekka Paalanen <ppaalanen at gmail.com> wrote:
>> On Fri, 29 Aug 2014 23:35:37 -0700
>> Jason Ekstrand <jason at jlekstrand.net> wrote:
>>> On Aug 29, 2014 6:25 PM, "Derek Foreman" <derekf at osg.samsung.com> wrote:
>>>> On 29/08/14 06:42 PM, Jason Ekstrand wrote:
>>>>> I haven't had a chance to look that hard at or play with this patch
>>>>> Hopefully I can look at it before too long. One quick question
>>>>> Have you verified that this works with all of the output transforms?
>>>>> sorry if this seems premature but a) pixman renderer stuff is hard to
>>>>> right and b) people are constantly breaking the pixman renderer with
>>>>> respect to output transforms. So I thought the question was worth
>>>>> even if I haven't had time to review yet.
>>>> Ouch - I am now guilty of 'b'
>>> That's OK. I, for one, can never get pixman changes right on the first
>>> try. That's why I asked. ;-)
>> We'd really need to hook pixman renderer into the headless backend, let
>> the test extension do screenshots, and write some tests to test all the
>> output transforms... it's a big task, but would be hugely useful and
>> allow to write more tests that can check real on-screen results. I've
>> been dreaming about that for a while.
FWIW that's on my TODO list right now, just haven't really started it
yet. Perhaps I should give it a higher priority.
>>>> Transforms do indeed break - the zoom translation is being applied in
>>>> the wrong direction for some, and the clip region needs to be rotated
>>>> for others.
>>>>> FWIW, I have a series on my github that accomplishes the same thing
>>>>> with substantially deeper changes to Weston:
>>>> I think I can re-work my patch to handle rotations/flips pretty easily,
>>>> though the code will bulk up a little.
>>>> Is that worth the time, or would you prefer to move forward with yours?
>>> I think mine is ultimately a better way forward. The big advantage is
>>> it provides a surface to/from buffer coordinates matrix and gets rid of
>>> of the transform logic from the pixman renderer. Part of the reason the
>>> pixman renderer is always breaking is that it's a separate
>>> path from the go renderer and the two can get out of sync. Also, pixman
>>> does things more-or-less backwards from GL so it's hard to get right.
>>> My patches shouldn't need much of a rebase. The reason I never pushed
>>> was that fixing zoom in the pixman renderer was never the end objective
>>> I never considered the series really finished. However, if else want
>>> zoom+pixman, they are probably good to go.
>> Oh yeah, finishing Jason's transformations revolution would be very
>> good. I should probably take a quick look if someone wants to pick it
>> up, since I don't recall if/what we agreed on the basic principles like
>> weston_matrix vs. pixman matrix etc.
>> Pixman is not the only rendering path that has to manually unravel and
>> redo everything, rpi-renderer is the other one. Currently Weston's core
>> has been written to support only the GL-renderer with its funny
>> normalized GL coordinate spaces, which means the common transformation
>> code (like output zoom handling) is practically useless for any other
>> renderer that might (*gasp*) want to deal with pixel coordinates.
> You should look at my patches. They fix some of that. :-) Don't quite fix
> the rpi stuff though.
> I got a fair ways with those patches but blocked on a few things and then
> didn't have time to finish. Here's roughly what needs to be done:
> 1) Add region transform code that transforms a region based on a matrix.
> 2) Use said region transform code to do region transforms instead of the
> current ints+enum version
> 3) Write a function to detect if a matrix is a combination of integer
> translation, integer scale, 90-degree rotation, and possible flip. If it
> is, return the data needed to reconstruct it as such.
> 4) Use said function for a bunch of things;
> a) Inside of the GL renderer to determine whether GL_LINEAR or
> GL_NEAREST should be used
> b) Inside of the DRM backend to determine if something can go in a
> c) Maybe in the RPI renderer for some things?
> That's a rough sketch for what I had intended. Then there was stuff about
> damage coordinates but that's blocking on getting at least 2) if not 3).
I'm quite willing to pick that up if you don't mind the occasional silly
question on IRC...
>> The current code also makes using hardware overlays in e.g. DRM-backend
>> more of a hassle than it needs to, because there too you would like to
>> have the end-to-end pixels-to-pixels transformation to program the
>> So roughly the big idea would be that Weston core provides coordinates
>> and transformations end-to-end from buffer to output in raw pixels, and
>> if the renderer has something strange like GL, it should do the
>> adaptation in its own code.
>> I don't recall complaints about zoom on pixman renderer, but maybe
>> that's because I've known it is broken.
I found it in the bugzilla (80258) - though the user thought it was a
problem with transparency and misreported it.
The problem isn't really a lack of zoom, more the incredibly anti-social
way in which weston reacts to the lack of zoom.
Once you enable zoom it starts dumping the same "zoom not supported"
warning into the log file every time a frame should be rendered, and
never actually rendering. It gives the impression that weston is
crashed, when it's actually just not bothering to do anything visible.
I guess I'll send another patch that makes it log the warning once, and
just continue to draw without the zoom. I suppose maybe we don't want
to paper over this one, but to me the failure mode seems a little heavy
handed and it's pretty easy to accidentally enable zoom when you intend
to adjust window transparency.
>> IMHO, working towards that testing thing or pushing Jason coordinate
>> revolution forward would be time better used than patching pixman
>> renderer case by case.
Nod - fixing my patch to provide output rotations would continue the
proliferation of ugly switch statements in the pixman renderer.
>>>>> On Aug 29, 2014 7:56 AM, "Derek Foreman" <derekf at osg.samsung.com>
>>>>>> Currently if you try to zoom with mod+scrollwheel the pixman
>>>>>> backend will stop rendering anything at all and will continuously
>>>>>> log "pixman renderer does not support zoom", giving the impression
>>>>>> that the server is hung.
>>>>>> Instead, this patch adds the missing zoom functionality.
>>>>>> This should close BUG 80258
>>>>>> src/pixman-renderer.c | 65
>>>>>> 1 file changed, 59 insertions(+), 6 deletions(-)
> wayland-devel mailing list
> wayland-devel at lists.freedesktop.org
More information about the wayland-devel