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