| zzag |
| KWin |
To streamline Compositor code more remove the composite reset timer. The two
times it was used we can either use a singleshot timer instead or connect the
call to a different signal in the X11 backend.
Long term goal is to have a well structured init of the Compositor such that
we can call directly instead.
Manually in X and Wayland nested session.
| Automatic diff as part of commit; lint not applicable. |
| Automatic diff as part of commit; unit tests not applicable. |
The connect in the X11 backend instead of using the timer should have the same effect, since it's proxied through this startChangedTimer at the beginning of the event receiver.
So, with this patch, Screens' m_changeTimer is used to compress composite resets, is it correct?
| plugins/platforms/x11/standalone/screens_xrandr.cpp | ||
|---|---|---|
| 56 | comp -> compositor | |
Yea, exactly. After the Compositor class has been split up and the Screens class has been removed it might make sense to add a compress timer back to the Compositor's X child class. For now I just want it gone to have less moving parts for the split up.
| composite.cpp | ||
|---|---|---|
| 115 | connect(&compositeResetTimer, &QTimer::timeout, this, &Compositor::reinitialize); compositeResetTimer.setSingleShot(true); Only initializes the timer. I suppose we can drop this QTimer::singleShot thing, otherwise Compositor will be reinitialized (with no absolute good reason) several times during startup. | |
| composite.cpp | ||
|---|---|---|
| 115 | ... unless I'm missing something. It's not obvious why QTimer::singleShot is here. | |
| composite.cpp | ||
|---|---|---|
| 115 | No, you're right definitely. I just misread the old code. | |