when switch tab 5-10 sec and switch back value is changed because fps drop to 8fps and back to normal how to fix.
This is expected behavior. From MDN:
requestAnimationFrame() calls are paused in most browsers when running
in background tabs or hidden <iframe>s in order to improve performance
and battery life.
Related
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.
What is included in "Idle" and "Other" times into Sumary of Timeline tab in Chrome Developer Tools?
What causes so much inaction?
Why do these occur?
How to reduce these times? Is it possible?
Why the browser is inactivity for so long (in the context of idle time)?
At the beginning of more than 1.8 seconds nothing happens:
In the middle the "Idle" and the "Other" occupy about 0.3 seconds:
At the end of almost 3 seconds nothing happens:
In this example, we have almost five seconds of inactivity browser...
The "Idle" state occurs when the browser has not yet completed the final rendering of the page on the screen but must put the process on hold while waiting for missing data or resources needed to resume and complete it.
We can deal with long "Idle" periods, for example, when the browser waits for a synchronous response, which is generated for a long time on the server-side.
The "Idle" state should not be confused with the "Loading" state, which is the time the browser actually uploads the response (from the first to the last byte), not the time from sending the request to uploading the response.
The "Other" state represents the time of all browser activities other than those listed in the pie chart, such as DOM tree building, CSSOM and others.
This issue is partly explained on the "Render-tree Construction, Layout, and Paint" website.
I found part of the answer on Addy Osmani's blog:
In Frame mode, the shaded vertical bars correspond to recalculating styles, compositing and so on. The transparent areas of each vertical bar correspond to idle time, at least, idle on the part of your page. For example, say your first frame takes 15ms to execute and the next takes 30ms. A common situation is that frames are synchronized to refresh rate and in this case, the second frame took slightly longer than 15ms to render. Here, frame 3 missed the "true" hardware frame and was rendered upon the next frame, hence, the length of the second frame was effectively doubled.
But this does not exhaust the topic.
Example from which the chart included in the question did not use frames.
I still do not know how to shorten the time, and what is hidden under "Other".
Check out this topic
Idle is just that, nothing was going on so nothing to worry about as far as I know.
Other is "un-instrumented activity". Which is stuff that currently isn't able to be broken down. So, you can't analyze what was going on in there from the DevTools.
Using Start profilling and reload page button instead of Record button will give the results we are waiting, since it stops recording after page to finish the loading, reducing idle.
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.
On this page of Firefox-speed tips(a little dated, 2008), it says:
If you haven't moved your mouse or touched the keyboard for 0.75
seconds (the content switch threshold) then Firefox enters a low
frequency interrupt mode, which means its interface becomes less
responsive but your page loads more quickly. Reducing the content
switch threshold can improve performance, then, and it only takes a
moment. Type about:config and press [Enter], right-click in the window
and select New > Integer. Type content.switch.threshold, click OK,
enter 250000 (a quarter of a second) and click OK to finish.
What's meant by this "content switch threshold" - like switching tabs, for example?
The setting is documented in MozillaZine (the first result when I google for "firefox content.switch".
The documentation says Firefox's parser can be "interrupted" at a greater frequency which makes the UI more responsive but means that less time can be spent (in a given time range) for document parsing, so the page will load slower (from the user's perspective).
I don't know why it's called "content.switch" or why a parser can be "interrupted" - it makes it sound like the process is single-threaded and Firefox is using user-threads, but I don't know Gecko.
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).