On Mon, Sep 1, 2014 at 8:33 AM, Derek Foreman <[email protected]> wrote:
> On 01/09/14 04:52 AM, Jason Ekstrand wrote: > > 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. > > FWIW that's on my TODO list right now, just haven't really started it > yet. Perhaps I should give it a higher priority. > > >>>> 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). > > I'm quite willing to pick that up if you don't mind the occasional silly > question on IRC... > Cool! I would love to see that go forward, I just don't have the time at the moment to work on it. Silly IRC questions welcome! Just direct them at "jekstrand" --Jason > > > --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. > > I found it in the bugzilla (80258) - though the user thought it was a > problem with transparency and misreported it. > > The problem isn't really a lack of zoom, more the incredibly anti-social > way in which weston reacts to the lack of zoom. > > Once you enable zoom it starts dumping the same "zoom not supported" > warning into the log file every time a frame should be rendered, and > never actually rendering. It gives the impression that weston is > crashed, when it's actually just not bothering to do anything visible. > > I guess I'll send another patch that makes it log the warning once, and > just continue to draw without the zoom. I suppose maybe we don't want > to paper over this one, but to me the failure mode seems a little heavy > handed and it's pretty easy to accidentally enable zoom when you intend > to adjust window transparency. > > >> IMHO, working towards that testing thing or pushing Jason coordinate > >> revolution forward would be time better used than patching pixman > >> renderer case by case. > > Nod - fixing my patch to provide output rotations would continue the > proliferation of ugly switch statements in the pixman renderer. > > >> > >> 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 > > >
_______________________________________________ wayland-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/wayland-devel
