我正在开发一个简单的bjobs
应用程序,我注意到调整大小和移动-l
窗口会产生一个丑陋的闪烁,例如与QML
窗口相比。
所以我创建了2个测试应用程序来显示差异:
QWidgets:
QML:
正如您所看到的,QML
版本的应用程序闪烁非常难看,而QtWidgets
版本是干净的。现在,当你的用户界面越来越复杂时,这会非常难看。
你对此有什么了解吗?这是一个错误吗?是否有针对此问题的修复/解决方法?
答案 0 :(得分:4)
你可以试试这个:
int main(int argc, char* argv[]) {
QCoreApplication::setAttribute(Qt::AA_UseOpenGLES);
or
QCoreApplication::setAttribute(Qt::AA_UseSoftwareOpenGL);
第一个选项使用OpenGl2DirecX角度库(如Google Chrome)
第二个使用软件进行OpenGL仿真...对于小程序工作非常好,并且与Windows XP等旧操作系统100%兼容。
注意:您可以尝试使用Qt 5.7和新的Qtquick.Controls 2.0 ...执行得更好...... https://blog.qt.io/blog/2016/06/10/qt-quick-controls-2-0-a-new-beginning/
答案 1 :(得分:1)
就我而言,我通过添加下一个标志解决了这个问题:
{{1}}
但这会增加其他渲染问题。或者不是。
答案 2 :(得分:1)
调整QML应用大小的问题是关于更新具有过时几何形状的窗口。解决方法是同步更新并调整大小。
由于从更新计时器到渲染场景图可能会突然进行更新,从而可以随时更新窗口,因此会导致绘制几何形状已过时的内容。 https://bugreports.qt.io/browse/QTBUG-46074
应使用基本同步或扩展同步来同步调整大小和窗口更新。 目前,基本同步已在Qt中使用和实现,但仍需要将窗口更新(来自计时器)与Windows管理器中调整事件的大小进行同步。
但是,一如既往,有一系列问题:
当窗口调整大小的速度过快时,会出现此问题。 由于同步事件(来自WM)应始终发送,因此在上一个之后的下一个:
<= _NET_WM_SYNC_REQUEST是从WM发送的,大小现在正在更改。
_NET_WM_SYNC_REQUEST由应用程序接收和处理。
<=收到了其他一些事件,例如新的几何图形。
..更新内容,swapBuffers。
=>将_NET_WM_SYNC_REQUEST_COUNTER发送回WM。
<= _NET_WM_SYNC_REQUEST从WM重新发送,大小正在更改。
.. swapBuffers //这是问题所在,当窗口更改其几何形状时执行更新。
_NET_WM_SYNC_REQUEST已接收并再次处理。
因此,当_NET_WM_SYNC_REQUEST发送但尚未接收/处理后,出现(7)个swapBuffers时,就会发生此问题。
最后得出结论:
换句话说,基本同步或扩展同步都无济于事(至少没有_NET_WM_FRAME_DRAWN),因为无法知道何时实际调整大小。
扩展同步协议是尝试解决此问题的方法,但是,正如我所看到的那样,由于几何形状的实际更改是在不与客户端同步的情况下完成的,因此没有_NET_WM_FRAME_DRAWN,总是有机会使用过时的几何形状来更新窗口。
https://lists.freedesktop.org/archives/xcb/2019-February/011280.html
答案 3 :(得分:1)
在golang therecipe / qt中,这对我有帮助:
func main() {
var format = gui.NewQSurfaceFormat()
format.SetVersion(4, 5)
format.SetProfile(gui.QSurfaceFormat__CoreProfile)
format.SetRenderableType(gui.QSurfaceFormat__OpenGL)
format.SetSwapInterval(0)
format.SetDefaultFormat(format)
os.Setenv("QT_SCALE_FACTOR", "1")
ap := widgets.NewQApplication(len(os.Args), os.Args)
ap.SetApplicationName("APP 1.1")
系统:Linux debian 10 gpu:Radeon 570
但动画速度更快,因为并非所有帧都被渲染...