[PATCH] pixman-backend: add support for zooming

[Pekka Paalanen]

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.

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