<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Sep 1, 2014 at 2:37 AM, Pekka Paalanen <span dir="ltr"><<a href="mailto:ppaalanen@gmail.com" target="_blank">ppaalanen@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="">On Fri, 29 Aug 2014 23:35:37 -0700<br>
Jason Ekstrand <<a href="mailto:jason@jlekstrand.net">jason@jlekstrand.net</a>> wrote:<br>
<br>
> On Aug 29, 2014 6:25 PM, "Derek Foreman" <<a href="mailto:derekf@osg.samsung.com">derekf@osg.samsung.com</a>> wrote:<br>
> ><br>
> > On 29/08/14 06:42 PM, Jason Ekstrand wrote:<br>
> > > Derek,<br>
> > > I haven't had a chance to look that hard at or play with this patch yet.<br>
> > > Hopefully I can look at it before too long.  One quick question though:<br>
> > > Have you verified that this works with all of the output transforms?<br>
> I'm<br>
> > > sorry if this seems premature but a) pixman renderer stuff is hard to<br>
> get<br>
> > > right and b) people are constantly breaking the pixman renderer with<br>
> > > respect to output transforms.  So I thought the question was worth<br>
> asking<br>
> > > even if I haven't had time to review yet.<br>
> ><br>
> > Ouch - I am now guilty of 'b'<br>
><br>
> That's OK. I, for one, can never get pixman changes right on the first<br>
> try.  That's why I asked. ;-)<br>
<br>
</div>We'd really need to hook pixman renderer into the headless backend, let<br>
the test extension do screenshots, and write some tests to test all the<br>
output transforms... it's a big task, but would be hugely useful and<br>
allow to write more tests that can check real on-screen results. I've<br>
been dreaming about that for a while.<br>
<div class=""><br>
> > Transforms do indeed break - the zoom translation is being applied in<br>
> > the wrong direction for some, and the clip region needs to be rotated<br>
> > for others.<br>
> ><br>
> > > FWIW, I have a series on my github that accomplishes the same thing only<br>
> > > with substantially deeper changes to Weston:<br>
> > ><br>
> > > <a href="https://github.com/jekstrand/weston/commits/wip/transforms" target="_blank">https://github.com/jekstrand/weston/commits/wip/transforms</a><br>
> ><br>
> > Interesting...<br>
> ><br>
> > I think I can re-work my patch to handle rotations/flips pretty easily,<br>
> > though the code will bulk up a little.<br>
> ><br>
> > Is that worth the time, or would you prefer to move forward with yours?<br>
><br>
> I think mine is ultimately a better way forward.  The big advantage is that<br>
> it provides a surface to/from buffer coordinates matrix and gets rid of all<br>
> of the transform logic from the pixman renderer.  Part of the reason the<br>
> pixman renderer is always breaking is that it's a separate render/transform<br>
> path from the go renderer and the two can get out of sync.  Also, pixman<br>
> does things more-or-less backwards from GL so it's hard to get right.<br>
><br>
> My patches shouldn't need much of a rebase.  The reason I never pushed them<br>
> was that fixing zoom in the pixman renderer was never the end objective and<br>
> I never considered the series really finished.  However, if else want<br>
> zoom+pixman, they are probably good to go.<br>
<br>
</div>Oh yeah, finishing Jason's transformations revolution would be very<br>
good. I should probably take a quick look if someone wants to pick it<br>
up, since I don't recall if/what we agreed on the basic principles like<br>
weston_matrix vs. pixman matrix etc.<br>
<br>
Pixman is not the only rendering path that has to manually unravel and<br>
redo everything, rpi-renderer is the other one. Currently Weston's core<br>
has been written to support only the GL-renderer with its funny<br>
normalized GL coordinate spaces, which means the common transformation<br>
code (like output zoom handling) is practically useless for any other<br>
renderer that might (*gasp*) want to deal with pixel coordinates.<br></blockquote><div><br></div><div>You should look at my patches.  They fix some of that. :-)  Don't quite fix the rpi stuff though.<br><br></div><div>
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:<br><br></div><div> 1) Add region transform code that transforms a region based on a matrix.<br>
</div><div> 2) Use said region transform code to do region transforms instead of the current ints+enum version<br></div><div> 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.<br>
</div><div> 4) Use said function for a bunch of things;<br></div><div>     a) Inside of the GL renderer to determine whether GL_LINEAR or GL_NEAREST should be used<br></div><div>     b) Inside of the DRM backend to determine if something can go in a plane<br>
</div><div>     c) Maybe in the RPI renderer for some things?<br><br></div><div>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).<br>
<br></div><div>--Jason<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
The current code also makes using hardware overlays in e.g. DRM-backend<br>
more of a hassle than it needs to, because there too you would like to<br>
have the end-to-end pixels-to-pixels transformation to program the<br>
overlays.<br>
<br>
So roughly the big idea would be that Weston core provides coordinates<br>
and transformations end-to-end from buffer to output in raw pixels, and<br>
if the renderer has something strange like GL, it should do the<br>
adaptation in its own code.<br>
<br>
I don't recall complaints about zoom on pixman renderer, but maybe<br>
that's because I've known it is broken.<br>
<br>
IMHO, working towards that testing thing or pushing Jason coordinate<br>
revolution forward would be time better used than patching pixman<br>
renderer case by case.<br>
<br>
<br>
Thanks,<br>
pq<br>
<div class="HOEnZb"><div class="h5"><br>
> > > On Aug 29, 2014 7:56 AM, "Derek Foreman" <<a href="mailto:derekf@osg.samsung.com">derekf@osg.samsung.com</a>> wrote:<br>
> > ><br>
> > >> Currently if you try to zoom with mod+scrollwheel the pixman<br>
> > >> backend will stop rendering anything at all and will continuously<br>
> > >> log "pixman renderer does not support zoom", giving the impression<br>
> > >> that the server is hung.<br>
> > >><br>
> > >> Instead, this patch adds the missing zoom functionality.<br>
> > >><br>
> > >> This should close BUG 80258<br>
> > >> ---<br>
> > >>  src/pixman-renderer.c | 65<br>
> > >> ++++++++++++++++++++++++++++++++++++++++++++++-----<br>
> > >>  1 file changed, 59 insertions(+), 6 deletions(-)<br>
</div></div></blockquote></div><br></div></div>