[PATCH] pixman-backend: add support for zooming

Mon Sep 1 02:52:59 PDT 2014

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

--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.
>
> IMHO, working towards that testing thing or pushing Jason coordinate
> revolution forward would be time better used than patching pixman
> renderer case by case.
>
>
> 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(-)
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/wayland-devel/attachments/20140901/bd6555d8/attachment.html>