setForeGroundColor() execution speed

Develop Developer Questions
21

I can’t affirm the repaint was the only one responsible of problem, but doing an update() instead of repaint() solve the problem.

For what I saw (I tried to put some traces in paintEvent()) after 255 call to setForeGround():

  • With update(), the paintEvent() is called once at the end
  • With repaint(), the paintEvent() is called:
    – 255 times when mainwindow is 3840x2094 pixels size
    – 15 times when mainwindow is 454x352 pixels size

I’m not good enough to understand Qt underlying process, but even with 255 paintEvent(), I think it shouldn’t be so long but…

Grum999

1 Like
22

Seems like even if you just repaint that ~30x30 pixels widget, the whole window surface ends up being updated.

That’s why I suspect the window compositor also may have some influence here, like search for “Mutter 4k” on Phoronix and see how many performance issues Gnome had adressed in the last 2 years (after downplaying any such issues for like 5 years :stuck_out_tongue: But KDE/KWin also is slowly accepting that some more fundamental changes are due after the “KWinFT” fork…)

But it could also be in Qt’s own window compositng, I don’t know much about it either.