Weird Qt5 lags when creating windows

[Obi]

Hello! There is the following system:

Gentoo Linux with all the latest stable branch updates
Kernel 5.15.19 LTS
X.org Server 21.1.3
GeForce 660 / NVIDIA drivers 470.103.01
Qt 5.15.2
Lazarus 2.2.0
Free Pascal 3.2.2
Xfwm 4.16.1

The problem is the following. I compiled Double Commander from git repository. When compiling, I set lcl=qt5 in ENV variables.

Creating any windows is visually very slow. First, the window frame is drawn (using Xfwm), then, after about ≈500 ms, the window is filled with content. I recorded a video, you can watch it below.

https://imgur.com/mipUIOm

Surprisingly, when built with lcl=qt4, window rendering is much, much faster.

This problem has been reproduced for me for quite a long time, for two or three years, since of Lazarus 1.8.x. The entire graphics stack has since been updated many times, but the problem remains.

I also noticed that lags are practically absent in an empty project, perhaps the size of the created executable file somehow affects this. I made a simple application:

Code: Pascal  [Select][+][-]

1. procedure TForm1.Button1Click(Sender: TObject);
2. begin
3.   with TForm2.Create(Self) do
4.     try
5.       ShowModal;
6.     finally
7.       Free;
8.     end;
9. end;

The result is on video: https://imgur.com/zDy5LLL

All in all, it's quite a hindrance to using applications because, often, I press a sequence of buttons faster than the windows open. And until the window is created, it does not accept keyboard input. A classic example is deletion with confirmation. I press Delete and immediately Enter, but only pressing Delete works, and Enter has to be pressed again - after waiting for a window with a request to confirm the deletion to be drawn.

https://imgur.com/mcnibuD

The question, of course, is what could be the problem? Is it possible to fix it somehow? I am now forced to compile applications with lcl=qt4, but Qt4 is already removed from Gentoo, I have to use various tricks to keep it working on my system.

[zeljko]

It's pretty strange since Qt5 is much faster than Qt4 here, in any aspect
Try to build lclqt5 with -dQtUseNativeEventLoop or
try to start your application with -disableaccurateframe cmd line param.
Also, please test with ./yourapplication -style windows just to check if current style is doing something weird.
I don't know what else could produce such slowness, maybe strace ./yourapp can show something ...

[Obi]

It's pretty strange since Qt5 is much faster than Qt4 here, in any aspect
Try to build lclqt5 with -dQtUseNativeEventLoop or
try to start your application with -disableaccurateframe cmd line param.
Also, please test with ./yourapplication -style windows just to check if current style is doing something weird.

I have tried all 3 methods listed. Lag, unfortunately, did not stop.

I don't know what else could produce such slowness, maybe strace ./yourapp can show something ...

I am attaching the log from strace. At the very beginning, there are monotonous entries "poll ... (Timeout)" - at this moment I keep the mouse button pressed over the button from this video: https://imgur.com/mipUIOm

Immediately after I release the mouse button, next in the log are records of creating a new window.

https://pastebin.com/wkDcWvGC

[zeljko]

Really don't know, it's something about glib loop IMO

[Obi]

Really don't know, it's something about glib loop IMO

At the same time, I should also say that applications that use Qt5, but are written in other languages, such as C++, do not have such problems with window rendering performance. All my suspicions come down to libqt5pas. Even when compiling with lсl=gtk2 has no such problems.

Is there any way to profile this library? Maybe somewhere to insert a code that detects the rendering time in milliseconds?

[zeljko]

Maybe gprof or valgrind can help, really don't know. Besides that, I'm not sure that libQt5Pas is problem here. Are you sure that you've correctly compiled qt5 ws and your app with -dQtUseNativeEventLoop ? In this case it uses Qt5 event loop, so in that case it should work in same way as C++ Qt5 app. Also, what qt style you use on your desktop ?

[Obi]

Are you sure that you've correctly compiled qt5 ws and your app with -dQtUseNativeEventLoop ? In this case it uses Qt5 event loop, so in that case it should work in same way as C++ Qt5 app.

I added this flag to the libqt5pas compilation flags, while the compiler cursed for "-d", I changed it to "-D" - and the library was built with it. I am not a Lazarus programmer, I can do something wrong. I'm trying to find out the source of the problem, since the developer of Double Commander himself has no idea where the lags come from. By the way, I see the same problem in CudaText, another application on Lazarus/FPC.

Also, what qt style you use on your desktop ?

qt5ct, but with the windows style, as I mentioned above, it didn’t work faster.

[zeljko]

One more check please: can you disable QTSCROLLABLEFORMS in qtdefines.inc ?
Define QTSCROLLABLEFORMS means QAbstractScrollArea is central widget of form, when disabled it's pure QWidget, so without scrollbars (lighter).
You can also comment line 41 in qtobject.inc
QCoreApplication_setAttribute(QtAA_DontCreateNativeWidgetSiblings, True);

rebuild and test ...

[Obi]

I commented out QTSCROLLABLEFORMS first and didn't notice any difference. That is, the form did not draw faster. Then, leaving QTSCROLLABLEFORMS commented out, I commented out the line
QCoreApplication_setAttribute(QtAA_DontCreateNativeWidgetSiblings, True);
and again didn't notice any difference.

BUT. I've noticed that form content draws much faster when the mouse cursor is OUTSIDE the application window. I reverted all my changes, compiled the vanilla library code, checked again. And indeed, if the mouse cursor is inside the application window, rendering is slow, as in the video from the first post of this thread. And if I move the mouse outside the application window (the application itself remains active, I do not click on the on-screen button with the mouse, but press Enter on the keyboard), the rendering speed increases significantly. It becomes not directly instantaneous, but at the level of Qt4, which, in principle, satisfies me.

Does this tell you the reasons for this behavior?

[zeljko]

Thanks, I don't know why it differs in rendering when mouse is inside form, but that's the way to go obviously

[Obi]

What does obviously mean?

[zeljko]

Check why mouse pos slow down rendering on x11