D25299: Composite without timer on swap events

[Roman Gilg]

romangg added a comment.


  In D25299#576016 <https://phabricator.kde.org/D25299#576016>, @davidedmundson wrote:
  
  > Urgh, no.
  >
  > I had an unsubmitteed comment for moving forwards.
  >
  > This patch takes 1 step backwards in order to eventually go 2 steps forward.
  
  
  With this patch we don't go backwards. This was maybe true for the earlier series at 8d13729031 <https://phabricator.kde.org/R108:8d137290317a25aeff9b2abcc0914395e1903aa5> which got rid of all the super old dysfunctional code and after which frames were pushed without alignment on X11 and always with a full frame timer delay even with swap events. But this was merged also a month ago to master and nobody died. The patch series here does fix these issues.
  
  > A perfectly sensible strategy, but I don't like having master that goes backwards without a completely solid plan to go forward.
  >  The risk of things not getting completed and us releasing something that makes things worse are too high.
  
  "Perfect" and "completely solid" are unachievable and converging against it has diminishing return. So we need to find a balance between changes going in without any plan and safeguarding things to the point where everything is cemented in and does not move anymore. I am sure we would be at the same point of incomprehensible and faulty compositing as until only few months ago wouldn't I have been willing to take the risk not having implemented everything perfectly from the start.
  
  I had a plan and this one I outlined publicly in task T11071 <https://phabricator.kde.org/T11071> and the testing ground D23105 <https://phabricator.kde.org/D23105>. I got some feedback and adapted my plan on what I learned. Then I moved forward without further delays.
  
  > But I don't want to hold this up, so in order to resolve this in a way where we can all keep moving forward, I have a proposal:
  > 
  > - I'll approve it, but we merge this commit as-is into a feature branch, rather than master
  > - We can then then do the next review based on that branch
  > - We can work, hack, rebase and submit reviews on that branch (and vlad and I can help run and rebase it and whatever)
  > - Master stays "sunny"
  > 
  >   Then when we have the vsync timer we can merge this all into master. Everyone wins.
  
  Oh, I definitely would have wanted this in master anyways because then Fredrik can base his Nvidia work on it. Since I don't have such direct communication channels to him as to you and Vlad my assumption is that this would lead to unreasonable delay and/or frustration on his side.
  
  If we want to facilitate coordinated feature branch development aside from master we can talk about it, but currently no such facilities besides I guess some company-internal ones at Blue Systems are in place for such.

REPOSITORY
  R108 KWin

REVISION DETAIL
  https://phabricator.kde.org/D25299

To: romangg, #kwin
Cc: kwin, davidedmundson, zzag, LeGast00n, The-Feren-OS-Dev, sbergeron, jraleigh, fbampaloukas, GB_2, mkulinski, ragreen, jackyalcine, iodelay, crozbo, bwowk, ZrenBot, ngraham, alexeymin, himcesjf, lesliezhai, ali-mohamed, hardening, romangg, jensreuterberg, abetts, sebas, apol, ahiemstra, mart
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kwin/attachments/20191212/27328ae7/attachment.html>