QTableView and double buffering?
-
I was under the impression that QWidgets (ergo QTableView) would use double buffering to avoid having to do expensive redraws.
but i find it calling paint events when i'm just browsing the menu bar (windows)
or even just hovering the mouse (there are no mouseover calls, so no bits are changing, yet it is continuously redrawing items in the table)how can i make it stop?
-
that is unrelated to double buffering
-
Hi,
AFAIR no the raster engine does not.Update calls are compressed though.[edit: mixed double buffering with a different technique SGaist]
-
is there a bit i can flip that says "please doublebuffer this" so redraws (no model changes) can blit from the buffer and not ask all the widgets to do their (very expensive) drawing?
-
The manual says that double-buffering is on by default. I guess standard QTableView could be doing something that defeats the caching: not seen this myself.
The fact that you have overloaded the view's paintEvent() (or you would not be seeing this) makes it possible there's something odd you are doing. Is your overload accidentally triggering further updates? Are there delegates involved?
It's also possible the underlying model may be doing something odd, triggering frequent update() calls.
What is your model doing? Does the behaviour persist if you put a static QStandardItemModel in the view? -
it's possible further updates are triggered, though it's certainly not supposed to do that. i'll investigate that.
yes there are item delegates involved.
not sure what you're asking with "what is your model doing". it's an SQLite table.
i'm not able to simply replace what i'm doing with a QStandardItemModel, that would take weeks of work.
thanks for the ideas.but doesn't it seem strange that simply BROWSING THE MENU BAR would cause paint events instead of blit-from-double-buffer? also: only when the table has focus. if another view has focus, no paint events are triggered, even when the menus overlap the same areas.
