On Mon, Sep 1, 2014 at 2:37 AM, Pekka Paalanen <[email protected]> wrote:
> On Fri, 29 Aug 2014 23:35:37 -0700 > Jason Ekstrand <[email protected]> wrote: > > > On Aug 29, 2014 6:25 PM, "Derek Foreman" <[email protected]> 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" <[email protected]> > 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 [email protected] http://lists.freedesktop.org/mailman/listinfo/wayland-devel
