i found e spinning at 100% just with 1 windows in wayland... open 2
terminology wins and move mouse form one to the other... 100% cpu. e
was moving seemingly a cursor client window? to the same coord again
and again as it was hidden...
this fixes that. no more spinning cpu
Under some circumstances we can defer frame callbacks forever for clients
that are only visible on desk mirrors.
I'm not certain those circumstances should actually occur (Ref T5678) but
at least for now this is a trivial and harmless workaround.
Fix T5654
it seems like this is a good place to try, and this seems to resolve
some render updating issues on restart, such as with maximized chrome
windows
ref T5599
in the case where an object is being shown before it has been moved or
resized, a move operation will trigger a series of callbacks which force the
compositor to attempt an illegal operation (recursive show before resize)
fix T5521
this is now handled by the event grabber. many callbacks on this
object are due to clip changes instead of genuine mouse movements,
meaning that processing events can lead to further resizes during a
render cycle
now i resize some windows and am in a white box of death each time...
this is really unfriendly... so downgrade to an err ad this is a
recoverable error.
in the case where this path was reached during x11 nocomp, the client's pixmap
refresh would be deferred until the end of nocomp, even when the refresh would
otherwise end the nocomp. instead, force the refresh immediately.
fix T4887
in the case where effects are disabled, no animation is started for iconify
operations, so this should fall through to the normal hide/show paths
ref T5444
This reverts commit cd3490f35c.
this breaks many windows by preventing deferred resizing from occurring.
a window which is unable to resize at the time of this call must be queued
for a deferred resize, otherwise it may never resize at all and thus will
never be rendered
test case: screenshot dialog
animating comp objects persist after the lifetime of their client, so
ensure that functions which are likely to be called after the client's free
will not attempt to access client struct members
we did cast to Evas_Native_Surface * but this just causes warnings due
to the input ptr being char * from memcup. as this will be aligned due
to allocation, we're ok, so use a void * cast instead
so on 1 intel laptop and my rpi i'm seeing 100% cpu usage in wayland
mode. it seems something is resizing to 0x0 and then causing a size
change which causes a property change which causes... another request
to 0x0 and repeat. dont set tyhe size changed flags if size actually
didnt change and this fixes that.
Mike Blumenkrantz
Carsten Haitzler
Derek Foreman