After upgrading to qt version 6.2 from qt5 I faced the problem with starting the app in the maximized mode. The widget is first painted with it's normal size and then repainted fine. The intermediate state is shown on the gif below:
The code of the app from the giff comes together with Qt (my version is Qt-6.2.3) and called "styles" (path is Qt/Examples/Qt-6.2.3/widgets/widgets/styles) or can be found on the qt.io. I have just changed widget.show() to widget.showMaximized() in main.cpp.
I figured out that sometimes widget starts fine, but this is rather rare. Also the more complicated widget is, the more time it takes to correctly paint it on the first show.
In the example from the gif the start is so quick that it is almost invisible, but in the heavy app I'm working with this slow startup really catches the eye.
If this can not be easy fixed, does anybody have any idea how to mask this behaviour? I thought about painting the widget on the virtual framebuffer and moving it back to the main display right after first show, but I did not find any easy means to create it in c++.
Any help is appreciated.
EDIT:
I finally reported a bug to qt developers.
See QTBUG-104357
Related
To make it short: I have a bug regarding Qt in combination with optirun (or similiar things). I posted it already on here, but it is not solved yet. With updating to the Qt version 5.4 it occurs another bug. The working window is just in the upper left corner in the resolution 100x30. It looks a bit similar to the right picture from the bug report. But by manually resizing it, the fixed and bigger size of the rendering window can be restored. That everything looks normal again.
Is there the possibility to emit an resize event without manually resize the whole window? Currently, I tried to call the methods of the resize event manually, but this did not seem to work properly.
Has anybody another idea to solve this problem? Maybe I am not the only one with that bug or maybe someone can imagine another solution without manually resizing the window? Any help would be great.
All I want is that the start of the program creates instantly a bigger widget to render in it.
Edit (some more information):
I also tried to set a minimum size to the central widget in the UI-Designer of the QtCreator and this worked for all resolutions besides 1120x800 and at this resolution the program aborts while binding the framebuffer object. I know it's a bit strange, but that is the resolution I needed and I really don't know, why the manual resizing works, but not the initial one.
I would recommend that if you want to trigger a resize event, you do it using the postEvent mechanism. When a resize event is created, it's done using this system anyway so it conforms to what's happening under the hood. If you look on the Qt Docs for Events it has some discussion on sending and posting events, all you need then is to create a QResizeEvent object.
For a while I've been using SDL to write my 3D engine,and have recently been implementing an editor that can export an optimized format for the type of engine Im building. Right now the editor is fairly simple, objects can just be moved around and their textures and models can be changed. As of right now, I'm using SDL with OpenGL to render everything, but I want to use Qt for the GUI part of the editor, that way it looks native on every platform. I've got it working great so far, I'm running a QApplication inside of the SDL application, so it basically just opens 2 windows, one that uses SDL and OpenGL, and the other using Qt. Doing a bit of research, I've found that you can manually update a QApplication, which totally removes any threading problems, and everything works. Just in case you're having a hard time visualizing this, heres a picture:
What my goal is to merge these windows into one, because on smaller screens (like my laptop's) it makes it really hard to keep track of all the different windows that I would eventually have. I know theres a way to render to Qt with OpenGL, but can this be integrated with SDL? Am I going to need to move away from using an SDL window and use a QT one if the editor is enabled? Just to clarify, when the engine isn't in editor mode, it won't use and Qt, just SDL, so optimally I wouldn't need to do this.
Drop the SDL part. You have Qt, which does everything SDL does as well. Just subclass a QGLWidget and use that.
You can keep your game and editor separate processes and still make them part of the same app.
Just spawn the window where you want the game to run as part of Qt, and at least in windows, you can then pass the window handle to your game, and make sure when your game is setting up, instead of creating the window yourself in SDL and binding the opengl context to it, you can actually bind to the existing handle.
There are some gotchas with this technique to watch out for such as input focus I believe (I tested with directX, but it might be similar with SDL). The problem is that the foreground mode does some dumb checks on the "root" window which for me was not the window that owned the opengl context, so it failed to initialize. However background mode worked. I think that was for a joystick now that I think about it, but anyway, that's how you can merge everything together.
I am writing an application which will allow the user to scrub through an open video. Developing on Windows 7/8 with Qt 5.3, I have been using QMediaPlayer and QVideoWidget following the qvideowidget example project. The result has been pretty good, except that the QVideoWidget seems only to update during idle time. Still, it's a good start and it's usable.
However, when I build on Mac OS 10.10 (again with Qt 5.3), scrubbing behaves as though there were only one frame per second in the video. As I drag the "position" slider, the video jumps from one frame to the frame one second later, then one second after that, even though I am calling QMediaPlayer::setPosition several times with positions between those two frames.
The problem can be reproduced using the videowidget example that ships with Qt 5.3 here: Qt\Examples\Qt-5.3\multimediawidgets\videowidget. When the slider is dragged on a Windows machine, the QVideoWidget moves between frames that are spaced fairly close together. When the slider is dragged on a Mac (at least on mine), the QVideoWidget jumps between frames spaced about one second apart. No matter how long I wait for an "in between" frame to render, it won't happen unless I hit the "play" button.
I've tried calling QMediaPlayer::play() and QMediaPlayer::pause() one after the other to force an update, but this doesn't seem to work--QMediaPlayer works asynchronously, so the update doesn't have time to take effect.
If I check the value of QMediaPlayer::position, I find that it actually doesn't change between these jumps. It appears that when I call QMediaPlayer::setPosition, it is actually rounding the position to one second increments on a Mac and finer increments on a Windows machine.
Ideally, I would like to jump to a particular position in the video and render that frame immediately on the QVideoWidget. Is there any way to force QMediaPlayer to set the position accurately and update the associated QVideoWidget? Is there a better way to implement smooth scrubbing in a video?
Thanks for your help!
In case anyone else has a similar problem...
My best guess is that the issue stems from limitations in the codec used by QMediaPlayer, since this seems to be the main difference between the two platforms. Rather than deal with the codec issues directly, I looked around for other options.
MLT (http://www.mltframework.org/) seemed promising, but it is a major pain to compile and the primary author seems to have settled on offering SDK support to commercial users only.
libVLC (https://wiki.videolan.org/LibVLC/) looks a lot better. In particular, I’ve been using vlc-qt (https://github.com/ntadej/vlc-qt). The latter has an interface that will look quite familiar to users of QMediaPlayer and QVideoWidget. It was an easy replacement in my own application, and the result was much smoother video scrubbing on both Windows and Mac.
Hope this helps someone else!
I'm using Qt5 in Windows. I just created a simple little widgets project in Qt Creator. I have a QMainWindow with a text edit widget inside. I enabled vertical layout, so the text edit consumes the full size of the inside of the main window (which is what I want, I'm trying to create a small notepad app).
As I drag the bottom right corner of the main window during the preview (I click the green triangle in the bottom left) I'm seeing a slight delay in the child widget's resizing. It doesn't exactly resize with the parent window on the same render frame (it seems like it is 1-2 render frames behind).
I remember years ago dealing with render lag like this in old school Win32 API. I remember I had to do double-buffered rendering into an offscreen bitmap to fix it (or something along those lines; been a long time).
Is there a way to fix this "render lag" in Qt? I can only imagine this is specific to Windows and might not impact other platforms, although I have not tested. If I need to provide more information let me know.
It is likely a Windows problem, not Qt's. The more GUI-heavy your window is the more noticeable it is.
I investigated the same issue a while ago. We had a rather GUI-heavy window, with several widgets displaying 2D and 3D views of data. Resizing the window using lower-right corner resulted in a resize-redraw horror. Unfortunately it looks like the problem is not Qt related but rather the way that Windows handles redrawing a resized window. I was able to notice the problem even in the file explorer on Windows 7. Qt is indeed using double buffering by default (as mentioned in the comment by #Bim). I also tried explicitly triggering Qt's repaint events. This helped a little, but did not solve the problem. So after many efforts we just decided to live with it.
I have an app that mixes OpenGL with Motif. The big main window that has OpenGL in it redraws fine. But, the sub windows sitting on top of it all go black. Specifically, just the parts of those subwindows that are right on top of the main window. Those subwindows all have just Motif code in them (except for one).
The app doesn't freeze up or dump core. Data is still flowing, and as text fields, etcetera of various subwindows get updated, those parts redraw. Dragging windows across each other or minimizing/unminimizing also trigger redraws. The timing of the "blackout" is random. I run the same 1-hour dataset every time and sometimes the blackout happens 5 minutes into the run and sometimes 30 minutes in, etc.
I went through the process of turning off sections of code until the problem stopped. Narrowed it down more and more and found it had to do with the use of the depth buffer. In other words, when I comment out the glEnable(GL_ENABLE_DEPTH_TEST), the problem goes away. So the problem seems to have something do with the use of the depth buffer.
As far as I can tell, the depth buffer is being cleared before redrawing is done, as it should. There's if-statements wrapped around the glClear calls, so I put messages in there and confirmed that the glClear of the depth buffer is indeed happening even when the blackout happens. Also, glGetError didn't return anything.
UPDATE 6/30/2014
Looks like there's still at least one person looking at this (thanks, UltraJoe). If I remember correctly, it turned out that it was sometimes swapping buffers without first defining the back buffer and drawing anything to it. It wasn't obvious to me before because it's such a long routine. There were some other minor things I had to clean-up, but I think that was the main cause.
How did you create the OpenGL window/context. Did you just get the X11 Window handle of your Motif main window and created the OpenGL context on that one? Or did you create a own subwindow within that Motif window for OpenGL?
You should not use any window managed by a toolkit directly, unless this was some widget for exclusive OpenGL use. The reason is, that most toolkits don't create a own sub-window for each an every element and also reuse parts of their graphics resources.
Thus you should create a own sub-window for OpenGL, and maybe a further subwindow using glXCreateWindow as well.
This is an old question, I know, but the answer may help someone else.
This sounds like you're selecting a bad visual for your OpenGL window, or you're creating a new colormap that's overriding the default. If at all possible, choose a DirectColor 24-plane visual for everything in your application. DirectColor visuals use read-only color cells, but 24 planes will allow every supported color to be available to every window without having to overwrite color cells.