[PATCH] pixman-backend: add support for zooming

Wed Sep 3 10:17:17 PDT 2014

On Mon, Sep 1, 2014 at 8:33 AM, Derek Foreman <derekf at osg.samsung.com>
wrote:

> 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:
> >>>>> Derek,
> >>>>> I haven't had a chance to look that hard at or play with this patch
> >> yet.
> >>>>> Hopefully I can look at it before too long.  One quick question
> >> though:
> >>>>> Have you verified that this works with all of the output transforms?
> >>> I'm
> >>>>> sorry if this seems premature but a) pixman renderer stuff is hard to
> >>> get
> >>>>> right and b) people are constantly breaking the pixman renderer with
> >>>>> respect to output transforms.  So I thought the question was worth
> >>> asking
> >>>>> 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
> >> only
> >>>>> with substantially deeper changes to Weston:
> >>>>>
> >>>>> https://github.com/jekstrand/weston/commits/wip/transforms
> >>>>
> >>>> Interesting...
> >>>>
> >>>> 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
> >> that
> >>> it provides a surface to/from buffer coordinates matrix and gets rid of
> >> all
> >>> of the transform logic from the pixman renderer.  Part of the reason
> the
> >>> pixman renderer is always breaking is that it's a separate
> >> render/transform
> >>> 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
> >> them
> >>> was that fixing zoom in the pixman renderer was never the end objective
> >> and
> >>> 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
> > plane
> >      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...
>

Cool!  I would love to see that go forward, I just don't have the time at
the moment to work on it.  Silly IRC questions welcome!  Just direct them
at "jekstrand"
--Jason

>
> > --Jason
> >
> >
> >> 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
> >> overlays.
> >>
> >> 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.
>
> >>
> >> Thanks,
> >> pq
> >>
> >>>>> On Aug 29, 2014 7:56 AM, "Derek Foreman" <derekf at osg.samsung.com>
> >> wrote:
> >>>>>
> >>>>>> 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
> > http://lists.freedesktop.org/mailman/listinfo/wayland-devel
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/wayland-devel/attachments/20140903/07394209/attachment-0001.html>