I'm developing a simple QML application right now and I noticed that resizing and moving a QML window generates an ugly flicker compared to a QtWidgets window, for instance.
So I created 2 test applications to show the difference:
QWidgets:
QML:
As you can see the QML version of the application flickers pretty ugly while the QtWidgets one is clean. Now this gets pretty ugly when your UI grows in complexity.
Do you have any knowledge about this? Is this a bug? Is there any fix/workaround for this issue?
You can try this:
int main(int argc, char* argv[]) {
QCoreApplication::setAttribute(Qt::AA_UseOpenGLES);
or
QCoreApplication::setAttribute(Qt::AA_UseSoftwareOpenGL);
The first option uses OpenGl2DirecX angle library (like Google Chrome)
The second one uses OpenGL emulation by software... for small programs work very good and is 100% compatible with old OS like Windows XP.
Note: You can try with Qt 5.7 and new Qtquick.Controls 2.0 ...performs much better...
https://blog.qt.io/blog/2016/06/10/qt-quick-controls-2-0-a-new-beginning/
The issue with resizing of QML apps is about updating a window with outdated geometry. The fix would be to sync the updates and resizing.
Since there might be sudden updates from update timer to render scene graph, which can update the window at any time, it causes drawing of the content with outdated geometry.
https://bugreports.qt.io/browse/QTBUG-46074
Either Basic or Extended synchronization should be used to synchronize resizing and the window updates.
Currently Basic sync is used and implemented in Qt, but still need to synchronize the window updates (from timer) with resizing events from Windows Manager.
But, as always, there is a list of issues:
The problem is observed when the window is being resizing too fast.
Since sync events (from WM) should be sent consistently, next after previous:
<= _NET_WM_SYNC_REQUEST is sent from WM, the size is changing now.
_NET_WM_SYNC_REQUEST is received and handled by app.
<= some other events received, like new geometry.
.. update the content, swapBuffers.
=> Sent _NET_WM_SYNC_REQUEST_COUNTER back to WM.
<= _NET_WM_SYNC_REQUEST is sent again from WM, the size is changing.
.. swapBuffers // here is the problem, the update is performed when the window is being changing its geometry.
_NET_WM_SYNC_REQUEST received and handled again.
So the issue happens when (7) swapBuffers appears after _NET_WM_SYNC_REQUEST is sent but not received/processed yet.
And finally conclusion:
Actual resizing of the window is started right after _NET_WM_SYNC_REQUEST is sent by The Window Manager. And not when the app receives it. The window could be even updated at this time, when sync request is sent, but not handled by the app yet. Which will draw the content with outdated geometry.
_NET_WM_FRAME_DRAWN could help to sync between resizing and updates, but also might not be supported (and guess it is not) by The Window Manager.
In other words, either basic or extended synchronization does not help, (at least without _NET_WM_FRAME_DRAWN), because there is no way to know when actual resizing is done.
Extended sync protocol is a try to handle this, but since actual changing of geometry is done without syncing with the client, as I can see, without _NET_WM_FRAME_DRAWN there is always a chance to update the window with outdated geometry.
https://lists.freedesktop.org/archives/xcb/2019-February/011280.html
In my case, i solved this by adding the next flag:
QQuickWindow::setSceneGraphBackend(QSGRendererInterface::Software);
But this will add other rendering problems. Or not.
In golang therecipe/qt this help me :
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")
System: Linux debian 10
gpu: Radeon 570
but the animations are faster because not all frames are rendered...
I am using Qt4.8 Windows version to develope an application to stream video using libvlc 2.2.1. When I use libvlc_media_player_set_hwnd() to render the video on my QWidget, its rather creating a separate window to display the video.
libvlc_media_player_set_hwnd(m_player, (void*)videoWidget->winId());
I have tried all versions of libvlc and all the examples related to libvlc with Qt. Also followed the steps given in https://wiki.videolan.org/LibVLC_SampleCode_Qt/
But I am not sure if I m missing anything.
It looks like as if libvlc_media_player_set_hwnd() is not able to take the QWidget WinId and creating its own window. However the value of (void*)videoWidget->winId() seems to be a valid one. (I got the value as 0x65).
Please let me know if I am missing anything.
You need to make sure you are configuring your VLC instance correctly first, so that it uses the dummy interface, for example:
/* Load the VLC engine */
std::vector<const char*> options;
options.push_back("--intf=dummy");
return libvlc_new(int(options.size()), options.data());
Also, are you sure you are passing the handle to the correct widget to render on? Also, make sure to set some size on the parent widget, otherwise you may not see anything render at all. Finally, check what media options you are setting to your media player instance, you may be inadvertently telling it to render to generated window.
I've been able to get VLC to work in my own Qt application using the following example as a starting point, even though it is for VLC 1.X:
LibVLC SampleCode Qt - VideoLAN Wiki
I’m developing a simple program with Symbian^3 Qt 4.7.3. User interface is constructed with QML and contains Text elements. I use FontLoader to load custom font and use Nokia 500 as a testing device.
In simulator (Mac) text rendering looks great…
http://korkalainen.net/text_qt_simulator_mac.jpg
…but in Nokia 500 the antialiasing looks like this (in my opinion it’s awful):
http://korkalainen.net/text_nokia500.jpg
Is there any way to improve or change the antialiasing settings used on the device? Thanks in advance for any help.
I had that problem too. The only solution was to go back to use the fonts preinstalled on the device.
I have a simple application that plays microphone - the code is taken from :
http://my.safaribooksonline.com/book/programming/android/9781449308001/exploring-the-apis/microphone#X2ludGVybmFsX0ZsYXNoUmVhZGVyP3htbGlkPTk3ODE0NDkzMDgwMDEvNDY=
This sample works fine on Ipad 2 but not on Ipad 1 (inconsistent behavior, sometimes plays a few seconds and breaks).
was anyone able to use the microphone on Ipad 1 (developed with flex 4.5.1), I need a very simple thing - record voice and play it
Thanks
Try increasing your buffer size for playback. This is located in the playSound function and in the example it is set to 8192 which should be more than enough. Try 16384 and see if that fixes it. Please note that this may make your playback seem to be delayed.
Are you compiling this application in Debug or Release mode to test? Sound playback is usually choppy in Debug mode and performs significantly better in Release.
I need to create a widget which shows battery status(in percentage) inside my qt application. Can anybody suggest me how to get the winXP api to know the battery status. Then as the api will return the percentage I will display on my widget....
I think this is the function you want.
http://msdn.microsoft.com/en-us/library/aa372693%28v=VS.85%29.aspx