Stop QProgressDialog from making dock icon bounce - macos

I have a function in my application that calls various subfunctions depending on the configuration. Each sub function is computationally intensive so I added a callback to update the status of a modal QProgressDialog. Each subfunction shows 0-100% completion of itself rather than the parent function.
If the dialog closes between subfunctions and the window doesn't have focus, the dock icon bounces. This can be seriously annoying if there are more subfunctions remaining as the user has switched focus away for a reason!
Is there a way to disable icon bouncing for when a QProgressDialog closes without focus ?

If I'm understanding correctly, the scenario you describe (even if working "correctly") leads to one of my pet peeves. That is: a progress bar which gets to the end, and then starts over at 0%. I'd rather a piece of software just say "working..." than give me an intentionally misleading progress bar!!
Why not divide your progress bar into phases, and then allocate each subfunction a section of the progress bar? In the simplest case, if you had two phases that were equal in duration you would let the first phase go from 0 to 50, and then the second phase from 50 to 100. This way you only put up and take down the progress bar once.
If the situation you have is complex, you'll need to do some pre-calculation to divide up the progress range (and a bit of ratio-oriented math). But even a crude approximation where the progress bar marches forward at an irregular speed from 0 to 100 is better than having it keep starting over!
Let's say there are three phases. The first takes a minute, the second takes two minutes, and the third takes a half hour. Sure--it would be somewhat strange to see it be 66.6% done after three minutes and then watch it slowly crunch through that last 33.3% for a half hour. But it's not as bad as going back to zero. Also, you should be able to estimate better than that. Even if something varies arbitrarily (such as an early phase reading a number N that can drastically affect a later phase)...can't you scan for that up-front? Allocate the scan maybe 5% of the time, and go from there.

If you set QProgressDialog::setAutoClose(false) the progress dialog will stay open between the subfunctions and stop the dock icon from bouncing.

Related

Is there any option to render list of 300 product and their details using pagination..?

I am already use Flatlist its working properly.
if i am scroll then loadmore data from pagination. I am load 20 product data from pagination API.
but its to late and slow for to render 300 product list. Is any Solution for my problem please tell me.
Advanced Thanks to all.
You can try the ones below :
Props One way to improve your FlatList is by tweaking it's props. Here
are a list of props that can help your with that.
removeClippedSubviews You can set the removeClippedSubviews prop to
true, which unmount components that are off of the window.
Win: This is very memory friendly, as you will always have a little
rendered list.
Trade offs: Be aware, that this implementation can have bugs, such as
missing content if you use it on a component that will not unmount
(such as a navigation route). It also can be less performant, having
choppy scroll animations for big lists with complex items on
not-so-good devices, as it make crazy amounts of calculations per
scroll.
maxToRenderPerBatch You can set the maxToRenderPerBatch={number},
which is a VirtualizedList prop that can be passed directly to
FlatList. With this, you can control the amount of items rendered per
batch, which is the next chunk of items rendered on every scroll.
Win: Setting a bigger number means less visual blank areas when
scrolling (a better the fill rate).
Trade offs: More items per batch means less JavaScript performance,
which means less responsiveness (clicking a item and opening the
detail). If you have a static and non-interactive list, this could be
the way to go.
initialNumToRender You can set the initialNumToRender={number}. This
means the initial amount of items to render.
Win: You can set this value to the precise number of items that would
cover the screen for every device. This can be a big performance boost
when rendering the list component.
Trade offs: You are most likely to see blank areas when setting a low
initialNumToRender.
windowSize You can set the windowSize={number}. The number passed here
is a measurement unit where 1 is equivalent to your viewport height.
The default value is 21, being 10 viewports above, 10 below, and one
in between.
Win: If you're worried mainly about performance, you can set a bigger
windowSize so your list will run smoothly and with less blank space.
If you're mainly worried about memory consumption, you can set a lower
windowSize so your rendered list will be smaller.
Trade offs: For a bigger windowSize, you will have a bigger memory
consumption. For a lower windowSize, you will have lower performance
and bigger change of seeing blank areas.
legacyImplementation This prop, when true, make your FlatList rely on
the older ListView, instead of VirtualizedList.
Win: This will make your list definitely perform better, as it removes
virtualization and render all your items at once.
Trade offs: Your memory consumption goes to the roof and chances are
good that a big list (100+) with complex items will crash your app. It
also fires a warning that the above tweaks will not work, because
you're now on a ListView.
disableVirtualization You will see people advocation the use of this
prop on some issues. But this is deprecated now. This used to do
something similar to legacyImplementation.
try the once above to display 300 data efficiently , if it doesnt work will tell you about pagination .
Hope it helps .feel freee for doubts

Initial object movement lag in applications while holding down arrow keys

In Windows applications, when a 'movement' is associated with a key ,namely scrolling down a web page by holding down (constantly, without releasing) the arrow keys or moving the objects in a game by doing so), the movement is performed like this: first a sudden and jerky movement takes place and then after a short instance the movement continues. However, in 'Role player games' this cannot be seen and we experience a smooth movement. What is the cause of this type of movement and how can it be solved while writing a Windows application? (Note that this is seen to be regardless of programming language.)
It's not an anti-pattern. It's intentional feature: for most of the time, you need to input a single character. Only after a delay, auto-repeat kicks in, because by holding the key you have clearly expressed that you need pretty many repeats. As you need pretty many, the repeat interval is smaller than delay after a single character.
The same behavior is extended onto the cursor keys.
If there were no delay after first cursor movement, most users would have hard time moving it by 1 letter. If you need to move exactly by 3 letters, you can get a precise result by triple-pressing.
You can control the delay and repeat speed in your Control Panel's keyboard settings.
In a specific application, normally, you subscribe to KeyDown/KeyUp events and handle the repeat functionality yourself. In games, you just check if a specific cursor key is down, and get equal movement on every cycle of the main loop.

Algorithm for animating elements running across a scene

I'm not sure if the title is right but...
I want to animate (with html + canvas + javascript) a section of a road with a given density/flow/speed configuration. For that, I need to have a "source" of vehicles in one end, and a "sink" in the other end. Then, a certain parameter would determine how many vehicles per time unit are created, and their (constant) speed. Then, I guess I should have a "clock" loop, to increment the position of the vehicles at a given frame-rate. Preferrably, a user could change some values in a form, and the running animation would update accordingly.
The end result should be a (much more sophisticated, hopefully) variation of this (sorry for the blinking):
Actually this is a very common problem, there are thousands of screen-savers that use this effect, most notably the "star field", which has parameters for star generation and star movement. So, I believe there must be some "design pattern", or more widespread form (maybe even a name) for this algoritm. What would solve my problem would be some example or tutorial on how to achieve this with common control flows (loops, counters, ifs).
Any idea is much appreciated!
I'm not sure of your question, this doesn't seem an algorithm question, more like programming advice. I have a game which needs exactly this (for monsters not cars), this is what I did. It is in a sort of .Net psuedocode but similar stuff exists in other environments.
If you are running an animation by hand, you essentially need a "game-loop".
while (noinput):
timenow = getsystemtime();
timedelta = timenow - timeprevious;
update_object_positions(timedelta);
draw_stuff_to_screen();
timeprevious = timenow;
noinput = check_for_input()
The update_object_positions(timedelta) moves everything along timedelta, which is how long since this loop last executed. It will run flat-out redrawing every timedelta. If you want it to run at a constant speed, say once every 20 mS, you can stick in a thread.sleep(20-timedelta) to pad out the time to 20mS.
Returning to your question. I had a car class that included its speed, lane, type etc as well as the time it appears. I had a finite number of "cars" so these were pre-generated. I held these in a list which I sorted by the time they appeared. Then in the update_object_position(time) routine, I saw if the next car had a start time before the current time, and if so I popped cars off the list until the first (next) car had a start time in the future.
You want (I guess) an infinite number of cars. This requires only a slight variation. Generate the first car for each lane, record its start time. When you call update_object_position(), if you start a car, find the next car for that lane and its time and make that the next car. If you have patterns that you want to repeat, generate the whole pattern in one go into a list, and then generate a new pattern when that list is emptied. This would also work well in terms of letting users specify variable pattern flows.
Finally, have you looked at what happens in real traffic flows as the volume mounts? Random small braking activities cause cars behind to slightly over-react, and as the slight over-reactions accumulate it turns into cars completely stopping a kilometre back up the road. Its quite strange, and so might be a great effect in your wallpaper/screensaver whatever as well as being a proper simulation.

Android: Counting time in my main loop

I'd like to a counter to run in the background while my game is being played so that when the player survives for say 1 minute, something happens.
Currently, I'm thinking of doing this by getting the system time at start (say in surfaceCreated) and then in my physics update method, getting the current time and comparing the two. When 60,000 ms have passed then I know obviously 1 minute has passed.
Is this the best way to do this? Or is there another/better/simpler way.
Thanks all
That's a good way to go about it.
There's not many other options. In my game, I have a stopwatch that stops resets right before the frame update, so I can determine the amount of time spent doing other things. Then, each object is stepped with this amount of time.
It's good because it allows me to move each object at a speed relative to time rather than framerate, so if framerate differs on a different device, things still move at the same speed.
If you're not doing this, you really should be. If your step function looks something like
object.x += speed.x;
then it really should be
object.x += speed.x (in units/s) * step_time (in ms) / 1000.0
If you are doing this, it's probably best just to make a timer object that runs a Runnable when the timer expires (i.e it sums up the step-times and fires when it reaches 60sec).

How do you separate game logic from display?

How can you make the display frames per second be independent from the game logic? That is so the game logic runs the same speed no matter how fast the video card can render.
I think the question reveals a bit of misunderstanding of how game engines should be designed. Which is perfectly ok, because they are damn complex things that are difficult to get right ;)
You are under the correct impression that you want what is called Frame Rate Independence. But this does not only refer to Rendering Frames.
A Frame in single threaded game engines is commonly referred to as a Tick. Every Tick you process input, process game logic, and render a frame based off of the results of the processing.
What you want to do is be able to process your game logic at any FPS (Frames Per Second) and have a deterministic result.
This becomes a problem in the following case:
Check input:
- Input is key: 'W' which means we move the player character forward 10 units:
playerPosition += 10;
Now since you are doing this every frame, if you are running at 30 FPS you will move 300 units per second.
But if you are instead running at 10 FPS, you will only move 100 units per second. And thus your game logic is not Frame Rate Independent.
Happily, to solve this problem and make your game play logic Frame Rate Independent is a rather simple task.
First, you need a timer which will count the time each frame takes to render. This number in terms of seconds (so 0.001 seconds to complete a Tick) is then multiplied by what ever it is that you want to be Frame Rate Independent. So in this case:
When holding 'W'
playerPosition += 10 * frameTimeDelta;
(Delta is a fancy word for "Change In Something")
So your player will move some fraction of 10 in a single Tick, and after a full second of Ticks, you will have moved the full 10 units.
However, this will fall down when it comes to properties where the rate of change also changes over time, for example an accelerating vehicle. This can be resolved by using a more advanced integrator, such as "Verlet".
Multithreaded Approach
If you are still interested in an answer to your question (since I didn't answer it but presented an alternative), here it is. Separating Game Logic and Rendering into different threads. It has it's draw backs though. Enough so that the vast majority of Game Engines remain single threaded.
That's not to say there is only ever one thread running in so called single threaded engines. But all significant tasks are usually in one central thread. Some things like Collision Detection may be multithreaded, but generally the Collision phase of a Tick blocks until all the threads have returned, and the engine is back to a single thread of execution.
Multithreading presents a whole, very large class of issues, even some performance ones since everything, even containers, must be thread safe. And Game Engines are very complex programs to begin with, so it is rarely worth the added complication of multithreading them.
Fixed Time Step Approach
Lastly, as another commenter noted, having a Fixed size time step, and controlling how often you "step" the game logic can also be a very effective way of handling this with many benefits.
Linked here for completeness, but the other commenter also links to it:
Fix Your Time Step
Koen Witters has a very detailed article about different game loop setups.
He covers:
FPS dependent on Constant Game Speed
Game Speed dependent on Variable FPS
Constant Game Speed with Maximum FPS
Constant Game Speed independent of Variable FPS
(These are the headings pulled from the article, in order of desirability.)
You could make your game loop look like:
int lastTime = GetCurrentTime();
while(1) {
// how long is it since we last updated?
int currentTime = GetCurrentTime();
int dt = currentTime - lastTime;
lastTime = currentTime;
// now do the game logic
Update(dt);
// and you can render
Draw();
}
Then you just have to write your Update() function to take into account the time differential; e.g., if you've got an object moving at some speed v, then update its position by v * dt every frame.
There was an excellent article on flipcode about this back in the day. I would like to dig it up and present it for you.
http://www.flipcode.com/archives/Main_Loop_with_Fixed_Time_Steps.shtml
It's a nicely thought out loop for running a game:
Single threaded
At a fixed game clock
With graphics as fast as possible using an interpolated clock
Well, at least that's what I think it is. :-) Too bad the discussion that pursued after this posting is harder to find. Perhaps the wayback machine can help there.
time0 = getTickCount();
do
{
time1 = getTickCount();
frameTime = 0;
int numLoops = 0;
while ((time1 - time0) TICK_TIME && numLoops < MAX_LOOPS)
{
GameTickRun();
time0 += TICK_TIME;
frameTime += TICK_TIME;
numLoops++;
// Could this be a good idea? We're not doing it, anyway.
// time1 = getTickCount();
}
IndependentTickRun(frameTime);
// If playing solo and game logic takes way too long, discard pending
time.
if (!bNetworkGame && (time1 - time0) TICK_TIME)
time0 = time1 - TICK_TIME;
if (canRender)
{
// Account for numLoops overflow causing percent 1.
float percentWithinTick = Min(1.f, float(time1 - time0)/TICK_TIME);
GameDrawWithInterpolation(percentWithinTick);
}
}
while (!bGameDone);
Enginuity has a slightly different, but interesting approach: the Task Pool.
Single-threaded solutions with time delays before displaying graphics are fine, but I think the progressive way is to run game logic in one thread, and displaying in other thread.
But you should synchronize threads right way ;) It'll take a long time to implement, so if your game is not too big, single-threaded solution will be fine.
Also, extracting GUI into separate thread seems to be great approach. Have you ever seen "Mission complete" pop-up message while units are moving around in RTS games? That's what I'm talking about :)
This doesn' cover the higher program abstraction stuff, i.e. state machines etc.
It's fine to control movement and acceleration by adjusting those with your frame time lapse.
But how about stuff like triggering a sound 2.55 seconds after this or that, or changing
game level 18.25 secs later, etc.
That can be tied up to an elapsed frame time accumulator (counter), BUT these timings can
get screwed up if your frame rate falls below your state script resolution
i.e if your higher logic needs 0.05 sec granularity and you fall below 20fps.
Determinism can be kept if the game logic is run on a separate "thread"
(at the software level, which I would prefer for this, or OS level) with a fixed time-slice, independent of fps.
The penalty might be that you might waste cpu time in-between frames if not much is happening,
but I think it's probably worth it.
From my experience (not much) Jesse and Adam's answers should put you on the right track.
If you are after further information and insight into how this works, i found that the sample applications for TrueVision 3D were very useful.

Resources