JavaFX Canvas delay - performance

I'm trying to convert some Java2D code to JavaFX and I'm stuck with an issue regarding the performance of the JavaFX Canvas. At some point, I'll have to draw thousands of small circles on the screen.
My problem is that in the first drawing, my code takes a lot of time to execute. But if I have to perform a second drawing, it takes only a fraction of the time to draw (it is at least 10 times faster).
Is there anything I'm doing wrong? Is there any way to prevent that initial delay?
I wrote this code to test it. In this code I draw 500,000 circles at random positions on a 1000 x 1000 canvas (built previously). I linked this code to a button click event, and on the first time I click it takes 10 seconds to execute. But if I just click again, it takes only 0.025 seconds.
private void paintCanvas() {
long initTime = System.currentTimeMillis();
GraphicsContext cg = canvas.getGraphicsContext2D();
cg.setFill(Color.WHITE);
cg.fillRect(0, 0, canvas.getWidth(), canvas.getHeight());
cg.setFill(Color.rgb(0, 0, 0, 0.1));
Random rand = new Random();
for (int i = 0; i < 500000; i++) {
cg.fillOval(1000 * rand.nextFloat(), 1000 * rand.nextFloat(), 2, 2);
}
long endTime = System.currentTimeMillis();
System.out.println("Time spent on drawing:" + (endTime - initTime)/1000.0f);
}
Actually there is no max number of new elements. It can vary from some hundreds to hundreds of thousands, depending of the users needs. And yes, it is ok if some elements pop in over time.

Guys I thank you for all help. I sent the same question to the OpenJFX mailing list and one of the developers answered. It seems that my JavaFX 2.2 version still use a old model for growing the command buffer. The new version, JavaFX 8, uses a more efficient model which makes the first painting as fast as the subsequent ones.
Here is the answer I got:
Jim Graham (james.graham at oracle.com)
Mon May 12 21:17:19 UTC 2014
This is likely due to growing the command buffer which was done
linearly at one point (probably still done that way in 2.2), but is
now exponential in 8.0. The first render time is nearly
instantaneous in
8.0, but takes a long time as you found when I try it with one of my old
2.x builds...
...jim

I can think of a couple things but let's start with one:
It could be that the JVM Just in Time compiler is hitting your execution. Depends on your JVM option (Whether it is client or server JIT, and whether you are using AggresiveOpts or not).
Remember, the JVM is smart enough to perform optimizations on that loop. In my opinion you can start there, put this on your JVM options when executing this: -XX:+PrintCompilation, and look at the output on console, your method should be compiled during the first execution and then you should not observe any compilations during the second. If this is so, then you know that this piece of code was compiled and stored in the CodeCache, and execution is not happening through the interpreter but through straight natively compiled code, which will have better performance.
Let us know your findings!
JVM options reference (might need to find your specific JVM doc):
http://www.oracle.com/technetwork/java/javase/tech/vmoptions-jsp-140102.html
P.S. can you try lowering the start time get right before you instantiate random?, it would be nice to be able to take two times, one at the beggining and right before the random, and the second, right after this last time and finally when the loop finished, the idea is to try and get a break down on where your code it's spending its time when you observe this (the loop, or the canvas instantiation).

Related

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).

About random number sequence generation

I am new to randomized algorithms, and learning it myself by reading books. I am reading a book Data structures and Algorithm Analysis by Mark Allen Wessis
.
Suppose we only need to flip a coin; thus, we must generate a 0 or 1
randomly. One way to do this is to examine the system clock. The clock
might record time as an integer that counts the number of seconds
since January 1, 1970 (atleast on Unix System). We could then use the
lowest bit. The problem is that this does not work well if a sequence
of random numbers is needed. One second is a long time, and the clock
might not change at all while the program is running. Even if the time
were recorded in units of microseconds, if the program were running by
itself the sequence of numbers that would be generated would be far
from random, since the time between calls to the generator would be
essentially identical on every program invocation. We see, then, that
what is really needed is a sequence of random numbers. These numbers
should appear independent. If a coin is flipped and heads appears,
the next coin flip should still be equally likely to come up heads or
tails.
Following are question on above text snippet.
In above text snippet " for count number of seconds we could use lowest bit", author is mentioning that this does not work as one second is a long time,
and clock might not change at all", my question is that why one second is long time and clock will change every second, and in what context author is mentioning
that clock does not change? Request to help to understand with simple example.
How author is mentioning that even for microseconds we don't get sequence of random numbers?
Thanks!
Programs using random (or in this case pseudo-random) numbers usually need plenty of them in a short time. That's one reason why simply using the clock doesn't really work, because The system clock doesn't update as fast as your code is requesting new numbers, therefore qui're quite likely to get the same results over and over again until the clock changes. It's probably more noticeable on Unix systems where the usual method of getting the time only gives you second accuracy. And not even microseconds really help as computers are way faster than that by now.
The second problem you want to avoid is linear dependency of pseudo-random values. Imagine you want to place a number of dots in a square, randomly. You'll pick an x and a y coordinate. If your pseudo-random values are a simple linear sequence (like what you'd obtain naïvely from a clock) you'd get a diagonal line with many points clumped together in the same place. That doesn't really work.
One of the simplest types of pseudo-random number generators, the Linear Congruental Generator has a similar problem, even though it's not so readily apparent at first sight. Due to the very simple formula
you'll still get quite predictable results, albeit only if you pick points in 3D space, as all numbers lies on a number of distinct planes (a problem all pseudo-random generators exhibit at a certain dimension):
Computers are fast. I'm over simplifying, but if your clock speed is measured in GHz, it can do billions of operations in 1 second. Relatively speaking, 1 second is an eternity, so it is possible it does not change.
If your program is doing regular operation, it is not guaranteed to sample the clock at a random time. Therefore, you don't get a random number.
Don't forget that for a computer, a single second can be 'an eternity'. Programs / algorithms are often executed in a matter of milliseconds. (1000ths of a second. )
The following pseudocode:
for(int i = 0; i < 1000; i++)
n = rand(0, 1000)
fills n a thousand times with a random number between 0 and 1000. On a typical machine, this script executes almost immediatly.
While you typically only initialize the seed at the beginning:
The following pseudocode:
srand(time());
for(int i = 0; i < 1000; i++)
n = rand(0, 1000)
initializes the seed once and then executes the code, generating a seemingly random set of numbers. The problem arises then, when you execute the code multiple times. Lets say the code executes in 3 milliseconds. Then the code executes again in 3 millisecnds, but both in the same second. The result is then a same set of numbers.
For the second point: The author probabaly assumes a FAST computer. THe above problem still holds...
He means by that is you are not able to control how fast your computer or any other computer runs your code. So if you suggest 1 second for execution thats far from anything. If you try to run code by yourself you will see that this is executed in milliseconds so even that is not enough to ensure you got random numbers !

What are some good approaches to predicting the completion time of a long process?

tl;dr: I want to predict file copy completion. What are good methods given the start time and the current progress?
Firstly, I am aware that this is not at all a simple problem, and that predicting the future is difficult to do well. For context, I'm trying to predict the completion of a long file copy.
Current Approach:
At the moment, I'm using a fairly naive formula that I came up with myself: (ETC stands for Estimated Time of Completion)
ETC = currTime + elapsedTime * (totalSize - sizeDone) / sizeDone
This works on the assumption that the remaining files to be copied will do so at the average copy speed thus far, which may or may not be a realistic assumption (dealing with tape archives here).
PRO: The ETC will change gradually, and becomes more and more accurate as the process nears completion.
CON: It doesn't react well to unexpected events, like the file copy becoming stuck or speeding up quickly.
Another idea:
The next idea I had was to keep a record of the progress for the last n seconds (or minutes, given that these archives are supposed to take hours), and just do something like:
ETC = currTime + currAvg * (totalSize - sizeDone)
This is kind of the opposite of the first method in that:
PRO: If the speed changes quickly, the ETC will update quickly to reflect the current state of affairs.
CON: The ETC may jump around a lot if the speed is inconsistent.
Finally
I'm reminded of the control engineering subjects I did at uni, where the objective is essentially to try to get a system that reacts quickly to sudden changes, but isn't unstable and crazy.
With that said, the other option I could think of would be to calculate the average of both of the above, perhaps with some kind of weighting:
Weight the first method more if the copy has a fairly consistent long-term average speed, even if it jumps around a bit locally.
Weight the second method more if the copy speed is unpredictable, and is likely to do things like speed up/slow down for long periods, or stop altogether for long periods.
What I am really asking for is:
Any alternative approaches to the two I have given.
If and how you would combine several different methods to get a final prediction.
If you feel that the accuracy of prediction is important, the way to go about about building a predictive model is as follows:
collect some real-world measurements;
split them into three disjoint sets: training, validation and test;
come up with some predictive models (you already have two plus a mix) and fit them using the training set;
check predictive performance of the models on the validation set and pick the one that performs best;
use the test set to assess the out-of-sample prediction error of the chosen model.
I'd hazard a guess that a linear combination of your current model and the "average over the last n seconds" would perform pretty well for the problem at hand. The optimal weights for the linear combination can be fitted using linear regression (a one-liner in R).
An excellent resource for studying statistical learning methods is The Elements of
Statistical Learning by Hastie, Tibshirani and Friedman. I can't recommend that book highly enough.
Lastly, your second idea (average over the last n seconds) attempts to measure the instantaneous speed. A more robust technique for this might be to use the Kalman filter, whose purpose is exactly this:
Its purpose is to use measurements observed over time, containing
noise (random variations) and other inaccuracies, and produce values
that tend to be closer to the true values of the measurements and
their associated calculated values.
The principal advantage of using the Kalman filter rather than a fixed n-second sliding window is that it's adaptive: it will automatically use a longer averaging window when measurements jump around a lot than when they're stable.
Imho, bad implementations of ETC are wildly overused, which allows us to have a good laugh. Sometimes, it might be better to display facts instead of estimations, like:
5 of 10 files have been copied
10 of 200 MB have been copied
Or display facts and an estimation, and make clear that it is only an estimation. But I would not display only an estimation.
Every user knows that ETCs are often completely meaningless, and then it is hard to distinguish between meaningful ETCs and meaningless ETCs, especially for inexperienced users.
I have implemented two different solutions to address this problem:
The ETC for the current transfer at start time is based on a historic speed value. This value is refined after each transfer. During the transfer I compute a weighted average between the historic data and data from the current transfer, so that the closer to the end you are the more weight is given to actual data from the transfer.
Instead of showing a single ETC, show a range of time. The idea is to compute the ETC from the last 'n' seconds or minutes (like your second idea). I keep track of the best and worst case averages and compute a range of possible ETCs. This is kind of confusing to show in a GUI, but okay to show in a command line app.
There are two things to consider here:
the exact estimation
how to present it to the user
1. On estimation
Other than statistics approach, one simple way to have a good estimation of the current speed while erasing some noise or spikes is to take a weighted approach.
You already experimented with the sliding window, the idea here is to take a fairly large sliding window, but instead of a plain average, giving more weight to more recent measures, since they are more indicative of the evolution (a bit like a derivative).
Example: Suppose you have 10 previous windows (most recent x0, least recent x9), then you could compute the speed:
Speed = (10 * x0 + 9 * x1 + 8 * x2 + ... + x9) / (10 * window-time) / 55
When you have a good assessment of the likely speed, then you are close to get a good estimated time.
2. On presentation
The main thing to remember here is that you want a nice user experience, and not a scientific front.
Studies have demonstrated that users reacted very badly to slow-down and very positively to speed-up. Therefore, a good progress bar / estimated time should be conservative in the estimates presented (reserving time for a potential slow-down) at first.
A simple way to get that is to have a factor that is a percentage of the completion, that you use to tweak the estimated remaining time. For example:
real-completion = 0.4
presented-completion = real-completion * factor(real-completion)
Where factor is such that factor([0..1]) = [0..1], factor(x) <= x and factor(1) = 1. For example, the cubic function produces the nice speed-up toward the completion time. Other functions could use an exponential form 1 - e^x, etc...

Creating a solid (framerate stable) game engine for OpenGL (ES)

I'm having trouble creating a solid game engine for my OpenGL application. It's a game which consists of several sprites with a lot of action.
I created objects which are basically all of my sprites. Another object called "gameEngine" loops through a set of calculations every something of a second (a timer), resulting in new game variables. After that, the sprite objects now know their drawing data.
The problem is, that after collecting all of my drawing data, the drawing should take place at exactly the right moment in time, resulting in a steady animation. Depending on the complexity of the current scene, the game calculations take an undetermined amount of time. So, the actual drawing takes place at different moments in time. How would I prevent that from happening?
To clarify, my approach goes something like:
// Every something of a second I call tick
-(void)tick
{
drawingData = gameEngine();
draw(drawingData);
}
There must be a best practice for building game engines like this I'm not aware of?
Game loops come in many varieties but the better ones separate the animation from the drawing or in more classic terminology model and view. Basically you want to construct a model of your game where you can establish the passing of time and update the model (physics framerate) and then independently render a snapshot of the model at consecutive moments in time (rendering framerate).
Here are a couple of articles which give a more detailed explanation of some of the variations on game loops and their pros and cons. There is source code too. I hope it helps.
Fix Your Timestep! and
deWiTTERS Game Loop Article
This really isn't about OpenGL; it's more to do with the operating system or system APIs you're using (i.e. Carbon/Cocoa/Win32). But the really, really simple case is this (pseudocode):
checkTime = currentTime
while not exitCondition
if currentTime - checkTime >= 50 milliseconds
checkTime = checkTime + 50 milliseconds
updateScene
else drawScene
You are drawing as often as you can, but only doing the updates every 50 milliseconds (i.e. 20 times per second). There are obviously a lot of other things to think about, especially in terms of what you do when you fall behind (skipping frames).
The best place to get into OpenGL stuff is Nehe's lessons:
http://nehe.gamedev.net/lesson.asp?index=01
They're getting a little dated, but the sample code at the bottom of each lesson is a great place to start, and it's available in many languages and for many operating systems.
The best solution would be a multi threaded application - one thread calculating the drawing data into a buffer and one rendering the data.
If you are looking for a realy simple solution, just invert the order of calculation and rendering.
void Initialize()
{
DrawingData = GameEngine();
}
void Tick()
{
Draw(DrawingData);
DrawingData = GameEngine();
}
You calculate the first drawing data on application start up and when the timer fires you just draw it. After that you have all the time up to the next timer event to calculate the drawing data again.
But in general it may be a better solution to render at a variable frame rate - you avoid the problems if the machine is to slow for your desired frame rate and you provide high frame rates on fast machines.
void Main()
{
StartTime = Now();
while (!ExitRequested)
{
DrawingData = GameEngine(Now() - StartTime);
Draw(DrawingData);
}
}
You render frames as fast as possible - not with a fixed interval between each frame but instead with the real time the application is running. That means do not advance your objects by 20 milliseconds every frame, just move them to the position the current running time says.
It's somewhat platform dependent, but one basic approach that usually works is to use a high performance timer in your render loop, and use it to help you sleep between frames in order to have a stable, steady framerate.
You can time your frame's rendering, and then sleep by the amount to maintain a stable framerate.
However, if your platform can't keep up with the framerate you want to achieve, you'll need to start looking at ways to optimize your game engine. This only works to slow down things to make them consistent and smooth - not to speed it up.
--- Clarification ----
-(void)tick
{
time = now() // from high perf. timer
drawingData = gameEngine();
newTime = now()
// pause for the time required to make the framerate consistent
Sleep(totalTimeForTickToBeStable - newTime + time)
draw(drawingData);
}

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