Xfwm4 compositor zooming patch
nick at xfce.org
Mon Nov 25 10:03:32 CET 2013
On Sat, Nov 16, 2013 at 5:56 PM, Alistair Buxton <a.j.buxton at gmail.com>wrote:
> I've made a new branch with some fixes:
> I think this still needs more testing before being merged, as the one
> person who reported it doesn't work got a completely black screen
> which is a pretty bad regression.
But the regression only occurs during zooming, so its not that bad. The
problem with the branch is that not a lot of people will test it.
> On 16 November 2013 10:49, Nick Schermer <nick at xfce.org> wrote:
> > Nice patch.
> > Small note about the code, please avoid "//" comments.
> Fixed. Also brace style fixed to match the rest of the code.
> > Another note is the timeout, I understand why you do this but the 32ms
> > a bit random (1000/60*2 is a better way to indicate you run it half the
> > for example). That said XQueryPointer is not the fastest function on this
> > planet so cpu usage becomes "high" why a user starts to zoom why not
> > the mouse. Maybe it is possible to use the mousemotion event for that,
> > this is probably limited because you need to grab the pointer for the
> > list of events. Duno if there are other options for this?
> Polling XQueryPointer is what compiz does. I realise compiz isn't
> known for being the best code in the world, but in this case the only
> alternative seems to be grabbing the mouse and doing input
> redirection, which is quite complex and has some problems. For some
> general background see:
> Xfwm4 compositor already gets the refresh rate of the display using
> randr. It is probably better to use that where available, rather than
> a hardcoded value.
Maybe the full refresh rate is a bit too much, half of it feels responsive
enough here. Also to cut the calls to XQueryPointer.
> If anyone has any better ideas...
> > The change to the clipping seems correct since paint_win only works on
> > rootBuffer. That said the function also applies its own clipping before
> > rendering so it might be redundant as well.
> Yes, paint_win sets the clipping region in every case when it is
> called from the first loop (because it also modifies it), so I guess
> the call is completely unnecessary.
If nobody has problems with it we merge this in master for wider testing,
then, in a week or so I can make a devel release.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Xfce4-dev