This seems to be a bit of a tricky one. Problem observed on Qt 5.9, 5.12 and 5.15.
In the app I am debugging on Mac (Jamulus), there is a main app window, and a non-modal tabbed settings window in which there are some QLabel items that get regularly updated with data values (a couple of times a second).
The problem is that if the settings window is displayed, but is not on top (the main app window is on top), and the user is not interacting with the program, the label updates result in steadily increasing memory usage. Then after some time (10 minutes or more), when the user next tries to interact with the program, the program goes busy (spinning ball) for a significant time before resuming. Once the program has resumed, the memory usage has gone down somewhat.
If the settings window is on top, the memory usage does not increase significantly.
It seems like there are objects being queued for deletion by the label updates, but that these deletions are only processed when the owning window is on top, and otherwise are queued for an event loop that doesn't run until the user interacts with the program again.
Is there a way to ensure these queued deletions get processed in the background as soon as they can be, rather than being queued up for a long time?
One further data item is that an older version of the program did not use a tabbed dialog for the settings window, just a simple dialog, and it doesn't suffer from this problem. It seems that maybe the tabbed dialog somehow gives rise to the issue.
This issue has only been observed on Mac, not on Windows or Linux.
Related
There are some controls on windows phone that behave different on the first interaction with them than on subsequent ones. e.g. a button control takes about 3-5 seconds to initialize the required action the first time the button is pressed, however on subsequent clicks it works immediately.
Another usercontrol that adjusts its height based on the key press doesn't adjust properly the first time, however the second time it works.
Is there a way to either prepare the controls, i.e. set them in a ready state so that all the clicks behave the same, or can first click can be faked to bypass this annoying behaviour?
Also what is causing this problem?
NB:- I am testing on a Lumia 520 device.
Unfortunately There is no way to prepare the controls. Nokia Lumia 520 comes in Lower Memory Device So Its behaviour seems slow at loading first time in memory and there are so many Background tasks also runnig at a same point of time. You should try it in Higher Memory Device and see the Behaviour.
I found out from this app performance document why it was happening , http://msdn.microsoft.com/en-us/library/windowsphone/develop/ff967560(v=vs.105).aspx#BKMK_Applicationstartup.
I have a loading panel that is set to collapsed by default and only set visible once the button is clicked. According to the document, elements in collapsed state arent added to memory, so this means the first time it needs to initialize the panel and it doesnt need to in subsequent tries.
The other UI control behaving weirdly was also due to its parent's height not being adjusted after its own height is adjusted the first time, so adjusting the parent height as well fixed it.
I am trying to implement frame independent movement in SFML, but am having trouble getting it to work. When I had this problem earlier with SDL, I found somewhere that Windows pauses the main thread of an application whenever it is moved (by dragging the title-bar). The problem comes because when the window is being dragged, the clock updates but the movement is not drawn until I let go of the window. When I move the window, the window is no longer being drawn to, but the time is still increasing. Thus, when I let go of the window, the units immediately jump to where they would be if the window had not been dragged.
I tried thinking of a solution, and since Windows only pauses the main thread, I considered just running the entire game in a separate thread, and launching it in main() but that does not appear to work as the same result occurs. I also thought about the extremely low FPS's I get as a result, but I would have no way of being able to differentiate between someone dragging the window and if their game is just naturally running slowly... There has to be a way to either prevent windows from pausing the main thread, or doing something that prevents this issue, but I haven't found any sort of solution on the internet...
Here is a link to a zip file which demonstrates the problem. Both Demo0 and Demo1 are the same, except Demo1 uses a second thread to run the program, yet the same effect occurs. Just run both and watch as the delta value is output to command line. Then drag the window and move it to some other part of the screen. When you let go, you should see a very large delta value and the circle should jump ahead depending on how long you had the window suspended. The source code is all there (in the "src" folder), so I hope people can understand the exact problem: http://www.sendspace.com/file/4er8f4
I see two solutions to the problem:
You can try to see if the sf::Events LostFocus or Resized picks up a window drag, and if they do, simply pause the clock on the game. More information can be found here: http://www.sfml-dev.org/tutorials/2.0/window-events.php
However, if that doesn't work, I would simply add an upper-cap on your delta. Meaning, if the game goes above a certain threshold of delta (1/60 or 1/30), you set delta to a lower value. In your situation though, this cap could probably be really big, like 1/15.
if(delta > 1/15.0f)
delta = 1/15.0f;
Chances are you don't expect your game to be playable at 15fps anyways, and if the user drags the window while moving, the worst you'll have to deal with is a 15fps delta on resume.
I develop audio plugins, which are run inside their hosts and work realtime. Each plugin has its own window with controls, which often contains some kind of analysis pane, a pretty big rectangle that gets repeatedly painted (e.g. 20-50x per second). This is all working well.
The trouble comes when the user adjusts a parameter - the plugin uses WM_MOUSEMOVE to track mouse movements and on each change calls ::InvalidateRect to make the relevant portion of the window be redrawn. If you move quickly enough, the window really gets quickly repainted, however there seems no time for the host and other windows to be redrawn and these usually perform some kind of analysis feedback too, so it is really not ideal.
No my questions:
1) Assuming the host and other window are using ::InvalidateRect too, why mine is prioritized?
2) How to make ::InvalidateRect not prioritized, meaning the window needs to be invalidated, but it may be later, the rest of the system must get time for their redrawing too.
Thanks in advance!
We're making a user-space device driver for OS X that moves the cursor using Quartz Events, and we ran into a problem when games — especially ones that run in a windowed mode — can't properly capture the mouse pointer (= contain/keep it within the boundaries of their windows). For example, it would go outside the game window and click on the desktop or nearby inactive applications.
We could fix this if only we could detect when an active application calls CGAssociateMouseAndMouseCursorPosition.
How would you do this? Any ideas are appreciated.
I dont know if this can help you
There is an option called Focus Follows Mouse
Focus Follows Mouse - The Mouse pointer will grab automatically change focus to a new window inisde this one app if you mouse over it, instead of having to click a window to get focus, then clicking to do something.
http://wineskin.urgesoftware.com/tiki-index.php?page=Manual+4.6+Advanced+-+Options
I have written a few different mouse logical layers (for bridging different input devices, etc.). I have found that hooking into the OS level WM_INPUT event is a sure way of getting very real-time mouse position information. There is also a less rigorous solution of just polling the mouse data you need from one of Windows' very primitive DLLs. They are lightning fast. You could poll on a 10ms timer and never see performance loss on a modern machine.
What MFC control should I use and how should I use it to display constantly changing text (like progress text) on a dialog?
For example, should I use the static text control? But can you change it programmatically?
Yes, you can change the contents of a static control programmatically. Change the ID to something other than IDC_STATIC, then you can assign a member variable to it. You can set the text with your_var.SetWindowText().
Edit: how many changes are you making, and how fast? I did a quick test program with a timer (set to a duration of 0) that formats and writes a new string to the control when the time fires, so it's updating constantly. Here's what it looks like after running for a while:
And here's what Task Manager shows:
The spike a the right is (at least mostly) from taking the screen shot of the test program saving it, and so on. As soon as I quit doing things like that, CPU usage went back to do noise level (with the occasional blip). I left the program running -- a half hour or so later, it's still doing fine, with no noticeable CPU usage (in fast according to Task Manager, it hasn't used even one second of CPU time yet).