Came across a problem which google searches could not help me with. I have a little SDL application that runs at 60 fps. Everything is working fine, however, it pauses/stops running when the window is dragged ( 640 X 480 window ). Is there a flag or something that can be set in the SDL window to prevent this from happening? Or is this unavoidable?
Windows uses a modal event loop for dragging windows, which blocks your main UI thread.
More discussion (and suggested workarounds, such as drawing from a second thread): http://www.sfml-dev.org/forum/viewtopic.php?p=8384&sid=632116a07a569edee43331076e028071
OpenTk apparently has code designed to address this, maybe you can reuse some of it: http://www.opentk.com/node/1218
Related
I have a win32 application which updates a lot of rectangles in a dialog quite fast. (now via bitblt(a bit of double buffering), before it was a different method - it doesnt matter).
And after random time passed - random dialog(from that application, with updating rectangles) just hangs on my PC. And by hanging i mean its redrawing hangs, if i push a menu button which popups something it works, but dialog doesnt shows anything just stays stuck. And it stays stuck until resized ! Or application restarted, ofc.
This only happens on my 'fast' PC with 3 desktops(controlled via different gpus).
My 'slow' laptop doesn't reproduce this, or maybe it would need more time to reproduce this(not a night, lets say) since its slower ?
I am really new in c++, windows dialogs programming - i may misused something or done something wrong. i checked everything i can, revisited microsoft tutorials on dialogs(and every drawing function) usage, checked everything - didnt quite found anything.
Maybe someone can offer me something smarter than disabling random functionality and waiting will it hang or not ? I would like to understand why it crashes(hangs), and why like this.
OS: Microsoft Windows 7 64
Compiler: Visual studio 2013
Addition: The debugger when stopped: Main thread shows only entrance of main dialog. DialogBox function, that's all. Ofc that thread is running all the other dialogs, but those dialogs are ran from main dialog called by DialogBox. Drawing is done by different thread, and it doesnt even notice that dialog hanged. The main thread doesn't 'hang' since other dialogs runs quite fine. and that 'hanged' dialog is fixed if resized, so strange.
Drawing by different thread means: dialogs are ran by main thread, other thread(actually couple of them and lower priority than other threads) is responsible for biblt and other drawing logic operations on those dialogs(since up to 600 rectangles can be updated up to 100Hz, it draws CPU quite well). I did addressed critical section problems and resources freeing when not used quite well but first thing i will do will be - rechecking those.
You're simply not supposed to draw from other threads.
It is however safe for a single thread to draw to a bitmap (i.e. in memory), and then hand off that bitmap to the main thread for bitblt'ing. That can scale in the sense that you can have multiple threads prepare multiple bitmaps, and have the main thread bitblt each of those in turn.
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.
Currently developing an APP using C++.
I am displaying multiple sub-windows in a single main window.
When one of the subwindows is put in Full Screen Mode , does the rendering of the other windows stop?
does the rendering of the other windows stop?
That depends on the implementation. If the program is implemented correctly, then the rendering should stop only if the window is fully covered.
Some people like to update the window in a timer callback (which is a bad practice), and then it would continue to render even when covered.
glutDisplayFunc is called only when there is a need to refresh the window.
EDIT: this app will run on Windows, Mac, and various Linux distros. I'm aware Linux has issues with this, but what about Windows? Mac?
Is there any way to get the width of the frame for a normal window, PRIOR to showing any windows? After showing a window, I know I can subtract the size() from the frameSize(), but that doesn't work until after the window is shown.
I've looked at QApplication::style()->pixelMetric(), and I can get the height of the title bar using
QApplication::style()->pixelMetric(QStyle::PM_TitleBarHeight)
but I don't see any options to get the width of the rest of the border around the window.
The only solution I've found so far is to:
set the window opacity to 0 (so the user doesn't see it),
show the window
then subtract size() from frameSize()
Is there a better way?
I posted a suggested solution in a different question at StackOverflow, but I'll post it here as well. You can move the window to somewhere far outside the screen before showing it and then query it for its geometry, and finally move it to where you want it (if that is what you need the geometry for). For instance to center a main window on the primary screen without flickering I do the following:
MainWindow mainWindow;
QRect primaryScreenGeometry(QApplication::desktop()->screenGeometry());
mainWindow.move(-50000,-50000);
mainWindow.show();
mainWindow.move((primaryScreenGeometry.width() - mainWindow.width()) / 2.0,
(primaryScreenGeometry.height() - mainWindow.height()) / 2.0);
I've only tested this code on Windows XP and Qt 4.8.x. Hopefully it works on other platforms as well.
In case you haven't seen it, the Qt doc page Window and Dialog Widgets contains a lot of information about this.
You don't say what platform you are running on, but it it's X11, the answer seems to be 'No', there isn't a better way:
X11 Peculiarities
On X11, a window does not have a frame until the window manager decorates it. This happens asynchronously at some point in time after calling QWidget::show() and the first paint event the window receives, or it does not happen at all. Bear in mind that X11 is policy-free (others call it flexible). Thus you cannot make any safe assumption about the decoration frame your window will get. Basic rule: There's always one user who uses a window manager that breaks your assumption, and who will complain to you.
(I like your workaround of setting the opacity to 0: neat!)
The python version of the answer by Daniel Hedberg.
One example to show window at screen's right bottom corner:
from PySide2 import QtWidgets, QtGui
app = QtWidgets.QApplication()
allScreensTotalWidth = sum([x.size().width() for x in QtGui.QGuiApplication.screens()])
allScreensTotalHeight = sum([x.size().height() for x in QtGui.QGuiApplication.screens()])
primaryScreenViewportWidth = QtGui.QGuiApplication.primaryScreen().availableSize().width()
primaryScreenViewportHeight = QtGui.QGuiApplication.primaryScreen().availableSize().height()
widget = QtWidgets.QWidget()
widget.resize(200, 200)
widget.move(allScreensTotalWidth, allScreensTotalHeight)
widget.show()
widget.move(
primaryScreenViewportWidth - widget.frameSize().width(),
primaryScreenViewportHeight - widget.frameSize().height())
app.exec_()
Sum of all QtGui.QScreen's size is the position not visible for user.
I have an application with an OpenGL window as a child window of the main window.
When I display a dialog box above the OpenGL window, it doesn't get drawn. It's like it's not getting WM_PAINT messages. If I can guess the title bar position of the dialog box, I can drag it and it's still responsive.
I realise this might be a vague question, but I was wondering if anyone else has seen this sort of behaviour before and knew of a solution?
I wondered if the Pixel Format Descriptor would make a difference - I had PFD_DRAW_TO_WINDOW, but changing to PDF_DRAW_TO_BITMAP didn't make any difference. I'm not sure what else I should be looking at?
Bugger. Should have given all the details. I was running Windows in a virtual machine on Mac OS X using Parallels. I upgrade from Parallels 3 to 4 and now everything is working fine. I suspect a Parallels video driver issue.
Thanks to all those who answered with suggestions.
Is your opengl window constantly rendering. It is possible that the 3D hardware is simply rendering into an overlay that is overdrawing your dialog box. If you position the dialog box so it overlaps your main window, can you see some of it?
Try to pause rendering into the main display to see if it effects the results.
You will also need to make sure that your window style ensures the results are clipped...
cs.style |= WS_CLIPSIBLINGS | WS_CLIPCHILDREN ;
You should check though all the items mentioned in this MSDN article, as it covers a lot of the basics for getting opengl rendering in a window correctly.
http://msdn.microsoft.com/en-us/library/ms970745.aspx
You may need to switch overlay off. It can be done via forcing back buffer presenting method to copy instead of swap.
Use wglChoosePixelFormatARB and one of parameters should be
WGL_SWAP_METHOD_ARB with value WGL_SWAP_COPY_ARB
This may seems stupid but are you sure your OpenGL window is not flagged "topmost" ?
Does the dialog box disappear also behind borders of your window or just behind the OpenGL rendering rectangle ?