Thread: 60FPS refresh loop

Hey everyone, I have a problem, I'm trying to make a loop which simply refreshes a jPanel 60 times a second. I've managed to do that, but I think I'm not doing it with the correct methods etc, as the line which was painted simply flickers and isn't constant. It should be more than visible at 60FPS. Here's the code i'm using:

Timer b = new Timer();
 
        TimerTask c = new TimerTask() {
            public void run() {
                a.Paint();
                a.Update();
            }
        };
 
        b.scheduleAtFixedRate(c, 0, 1000/FPS);

Update is a method i made within the jFrame which simply calls the repaint method of jPanel.
Paint draws a line. Example:

public void Paint() {
 
        g  = jPanel1.getGraphics();
        g.setColor(Color.red);
        g.drawLine(100, 100, 400, 100);
    }
 
    public void Update() {
        jPanel1.repaint();
    }

This program basically runs a very flickery line. I know i'm doing something very stupid, so help would be appreciated. Should I be using a completely different method?

Thanks,

I get much the same problem when trying this, which is a simplified version of earlier..

while(true) {
            a.Paint();
            a.Update();
            Thread.currentThread().sleep(1000/30);
        }

I remember having a similar problem with the JPanel thingy. I had a scrolly text (which would today be called an animated scrolling marque, for those people under 25), and only managed to squeeze about 20 frames per second. A Commodore 64 could have done the same sort of thing at 50FPS. Progress, eh?

I think the problem is that Java is about 20% slower than some other comparable languages, so the best way is to optimise your code, use stacked variables and so on. As to how to optimise code in Java, I don't know as the course I'm on seems to be showing me how to do things the long way around.

Good luck!

Regards,

Shaun.

That's not how you do painting. You almost never want to use the getGraphics() function like that. Just call repaint, and do the custom painting in an overriden paintComponent() method.

Originally Posted by ShaunB

I think the problem is that Java is about 20% slower than some other comparable languages, so the best way is to optimise your code, use stacked variables and so on. As to how to optimise code in Java, I don't know as the course I'm on seems to be showing me how to do things the long way around.

Sorry, but that's wrong. The problem is incorrect GUI code. In fact, much of Java's "reputation" for being slow has been caused by people not fully understanding GUI coding, especially with regard to painting and threading.

Originally Posted by Joe Moer

I get much the same problem when trying this, which is a simplified version of earlier..

while(true) {
            a.Paint();
            a.Update();
            Thread.currentThread().sleep(1000/30);
        }

And since I mentioned incorrect threading practices, I guess I should point this out: What Thread are you putting to sleep here? If it's the EDT, you're going to have a big problem with response time in an even slightly more complicated GUI.

Originally Posted by KevinWorkman

Sorry, but that's wrong. The problem is incorrect GUI code. In fact, much of Java's "reputation" for being slow has been caused by people not fully understanding GUI coding, especially with regard to painting and threading.

Perhaps, but it still helps if you have optimised your code. As for 'GUI' code, well I'm sure that I'll find out what this means. It would help if there was an emphesis on efficiency in my opinion, but there are too many people who think that this doesn't matter anymore. See some of the topics discussed on dailly.blogspot.com, particularly this and this.

Regards,

Shaun.

Originally Posted by ShaunB

Perhaps, but it still helps if you have optimised your code. As for 'GUI' code, well I'm sure that I'll find out what this means. It would help if there was an emphesis on efficiency in my opinion, but there are too many people who think that this doesn't matter anymore. See some of the topics discussed on dailly.blogspot.com, particularly this and this.

Regards,

Shaun.

Code optimization is important in a few cases, but premature optimization, especially with beginners, leads to all kinds of painful "shortcuts" that actually hurt the understandability, maintainability, and efficiency of the code.

Basically, the rule of thumb is: if you aren't having any performance problems, don't worry about it. If you are, make sure you're not making any basic mistakes (as is the OP's case, and probably 95% of other cases). If you're sure you aren't making any mistakes, THEN worry about optimization. Not before that though.

Says Donald Knuth: "We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil" (Program optimization - Wikipedia, the free encyclopedia)

Okay, if you insist. But those people who have programmed machine-oriantated languages, like assembly, and especially on legacy systems, always try to optimise to free up processor cycles to do something else with those cycles.

Regards,

Shaun.

Originally Posted by ShaunB

Okay, if you insist. But those people who have programmed machine-oriantated languages, like assembly, and especially on legacy systems, always try to optimise to free up processor cycles to do something else with those cycles.

Regards,

Shaun.

Fair enough. But we aren't talking about assembly. That's the beauty of Java: it's a high level language. If you write the code correctly, it will handle much of the optimization itself. So if you're having a problem, chances are its your fault, not Java's. Sure, some basics obviously still apply (don't loop through an entire Collection if you just want to deal with a single Object), but it's wrong to automatically blame performance on Java being slow. Java isn't slow unless you're doing something wrong.

I didn't say Java was slow, I said it is slower than some other comparable languages. And yes, it's the way you write the code, but that's down to how you're taught, and I know this because of the course I started Sept 2009.

The first programming assignment was to use a JFrame to draw a picture @ 600 x 600 pixels. On many of my fellow student's assignments, you could see the picture build up because they were using loads of nested loops to draw each different component. I used a variable stack and drew everything in one pass and you couldn't see it draw each bit of the picture (consider I was essentially using pixel-art here).

When I mentioned about using a screen buffer (no idea what this would be called nowadays? JPanel buffer? Window buffer? Object buffer?) and my tutor said "that would be complicated", well, not really. The theory may be complicated, but implementation is quite easy. And on my most recent assignment, the criteria stated to use loads of if...else if... statements or a switch/case thingy to return the corrosponding month name from an integer. If you'd have used a more logical look-up table, you would have failed [that bit of the criteria] even though it's a more efficient way of doing things and would essentially do the same job.

The other problem is that some industry veterans complain about these graduate programmers being a bit clueless, but it's not the graduate's fault if they've been taught in a particular way of doing things, is it?

Regards,

Shaun.

Originally Posted by ShaunB

I didn't say Java was slow, I said it is slower than some other comparable languages.

Which is false.

Originally Posted by ShaunB

And yes, it's the way you write the code, but that's down to how you're taught, and I know this because of the course I started Sept 2009.

The first programming assignment was to use a JFrame to draw a picture @ 600 x 600 pixels. On many of my fellow student's assignments, you could see the picture build up because they were using loads of nested loops to draw each different component. I used a variable stack and drew everything in one pass and you couldn't see it draw each bit of the picture (consider I was essentially using pixel-art here).

I can't really comment because I have no idea what the assignment was, or what the other students were actually doing. It doesn't make a ton of sense to me that you would be able to see the picture build up, unless they were doing something similar to what the OP doing, which is wrong.

Originally Posted by ShaunB

When I mentioned about using a screen buffer (no idea what this would be called nowadays? JPanel buffer? Window buffer? Object buffer?) and my tutor said "that would be complicated", well, not really. The theory may be complicated, but implementation is quite easy.

Are you talking about double buffering? Swing does that automatically.

Originally Posted by ShaunB

And on my most recent assignment, the criteria stated to use loads of if...else if... statements or a switch/case thingy to return the corrosponding month name from an integer. If you'd have used a more logical look-up table, you would have failed [that bit of the criteria] even though it's a more efficient way of doing things and would essentially do the same job.

It sounds to me like maybe you're just ahead of the class. Maybe the teacher wanted the students to learn if and switch statements and thought a "bad" example that uses a ton of them was the best way to go.

Originally Posted by ShaunB

The other problem is that some industry veterans complain about these graduate programmers being a bit clueless, but it's not the graduate's fault if they've been taught in a particular way of doing things, is it?

I graduated not too very long again, and even I complain that most programmers my age are clueless.

I'm 17, not even out of high school, and I finished all of the colleges Java courses with 100%.

if...else if and switch we covered in the first year. The second year is 'advanced programming' and yet we're still asked to use if... else if or switch case. What's advanced about that? Okay, it makes the assignment easier to mark for the tutors, but it's not advanced programming in my opinion.

I don't think I'm ahead of the class, I'm probable on par or behind. I'm just old-school, if you like, and have knowledge of 6502 and Z80. So, I'm more machine/hardware oriantated by default and struggle as programming has become far more abstract than it used to be.

If double buffering is done by Swing, why did the tutor say that buffering was complicated? Is this a problem with acedemics?

Regards,

Shaun.

Originally Posted by helloworld922

Most modern JVM's come with "Just-in-time compilation" allowing them to be compiled into machine language and run at the same speed as a C program. Granted, C/C++ programs allow you explicit control of memory management and other little tidbits that could make your program faster, but for 99% of the time Java will run at the same speed (or even faster as it's harder to write a well designed C/C++ program) for much less development time (same goes for C# which is Microsoft's "clone" of Java).

Thanks you so much! My friend, who thinks he knows something about programming ALWAYS says that Java is "super slow" and shouldn't be alive. He also states that LUA is more practical and efficient. (haha)

Originally Posted by helloworld922

When you call repaint() the default behavior is to clear the screen and then call the paint() method. This is likely why you're having flickering problems.

I agree with the first part of your post, but I'm not convinced this is the case. The OP is doing the wonky (incorrect) getGraphics() approach to painting. That's bad. I would think the OP should fix that before doing anything except the basic, traditional approach to painting: override paintComponent, call super.paintComponent first (yes, to clear the screen), then do the custom painting. Call repaint() whenever anything changes.

Originally Posted by helloworld922

A good solution is to over-ride the repaint() method to directly call paint() so you don't clear the screen.

I really disagree with this. If you really wanted to avoid clearing the panel, the way to do that is to override paintComponent and not call super.paintComponent. But I don't think that's a good idea in this case, either. If the OP is doing any moving of the painted stuff (based on resizing, or whatever), then that will actually break things pretty badly.

Originally Posted by helloworld922

Also, you should paint to a backup image in a separate method what you want drawn to the screen, then in your paint method you can just call paintImage() and that will update your whole screen (you'll only have to update the backup image when something changes).

Again, I would call this premature optimization. The OP should fix his basic problems before bothering with anything more complicated.

Originally Posted by ShaunB

If double buffering is done by Swing, why did the tutor say that buffering was complicated? Is this a problem with acedemics?

I can't speak for your teacher or tutor. I'm not sure what you actually asked them, so I'm not sure what they were saying was complicated. But this might be worth checking out: Painting in AWT and Swing

Originally Posted by Brt93yoda

Thanks you so much! My friend, who thinks he knows something about programming ALWAYS says that Java is "super slow" and shouldn't be alive. He also states that LUA is more practical and efficient. (haha)

Tell your friend to show you some benchmarks (compared to benchmarks in other languages) proving that Java is "super slow". Until then, he's talking nonsense.

Originally Posted by KevinWorkman

I can't speak for your teacher or tutor. I'm not sure what you actually asked them, so I'm not sure what they were saying was complicated. But this might be worth checking out: Painting in AWT and Swing

He was showing an example of a program from the previous year's first years (if that makes sense), and it was animated but had horrible flicker as though it was written in BASIC on a Sinclair ZX Spectrum or something using UDGs. I said 'why wasn't a screen buffer used', and he said something like 'that would be complicated'. That's the short version anyway.

But when I came to do this in my second assignment, it was really easy. From memory, it was something like g.drawScreen(backBuffer,this); just one line of code.

Sure, what's happening at the machine's level might be complex, but implementation is easy.

Regards,

Shaun.

Originally Posted by helloworld922

[SNIP]That was back in the day when computers were very slow so every cycle counted. However, on modern day computers most can get ~1GHz-2GHz clock speeds, so the loss of a few clock cycles here or there will result in literally nano-second losses[/SNIP]

1 cycle, at least on a 'fast' 8-bit processor like the 6502, is a nano-second if my memory serves.

Regards,

Shaun.

@OP, I hope that helloworld managed to solve your problem. He was correct in saying that the the reason the line was flickering was due to you rendering the line to the screen (in a bad manner) and the imediately clearing the screen afterwards. The only reason it was visible at all ways because you were rendering at 60 FPS if you drop it to say 2 FPS I'm sure you will see a much different result.

Buffering is a much more difficult concept than you can imagine. There is alot of Math behind the optimization of buffers, yes it may appear easy to implement which on a basic level it is. However, for true buffering it is not so simple. Never be fooled into believing you are doing something correctly just because it works.

If you can render a visual representation of Massive amounts of Data at 24 frames a second then well done, but this doesn't mean it is correct or optimized. As that same data will be cabale of being rendered at 30 FPS, interactive speeds. What I'm saying is that you may think you know better than your lectureres approach, but it isn't always true.

If you order if/else statements in the correct order and embedding they can actually prove very efficient 99% of the time, also a simple operation like that can be highly optimized by the compiler. When you start writing half-apt fancy algorithms which do things faster, you remove the ability for the compiler to optimize for you.

If you are trying to optimise simple applications which fall below 500 lines of code it is almost certain you are cause problems.

Chris

Originally Posted by Freaky Chris;22225 [SNIP

If you can render a visual representation of Massive amounts of Data at 24 frames a second then well done, but this doesn't mean it is correct or optimized. As that same data will be cabale of being rendered at 30 FPS, interactive speeds. What I'm saying is that you may think you know better than your lectureres approach, but it isn't always true.[/SNIP]

My lecturers approach was "buffering is complex", that was it. There was no suggestion of "... but try it anyway and see if you can get it to work, here is the theory, make that happen inside a visual display unit... etc..." I had a go myself and think I got it working, but only because I thought there would be good reasons for doing so. I don't think anyone else touched it, but then I think of programming differently than probably all of the students on my course because I was brought up in a different era. Probably why I find many concepts so difficult to grasp, like the idea of having no direct control of the computer's memory.

Regards,

Shaun.

Originally Posted by ShaunB

My lecturers approach was "buffering is complex", that was it. There was no suggestion of "... but try it anyway and see if you can get it to work, here is the theory, make that happen inside a visual display unit... etc..." I had a go myself and think I got it working, but only because I thought there would be good reasons for doing so. I don't think anyone else touched it, but then I think of programming differently than probably all of the students on my course because I was brought up in a different era. Probably why I find many concepts so difficult to grasp, like the idea of having no direct control of the computer's memory.

This will always be the case with lecturers, partly because it reduces their work load. Having to mark work which has taken extra iniative requires a lot more time as they are unable to quickly skim over code as they do for the standard response they are after.

Yes being brought up in a different era would cause you to want access to memory as you please, however that isn't done so much now days due to the fact it isn't required most of the time.

I personally have similar issues with my lecturers, so I know how it feels to not be pushed further ahead in areas. Do not dis-respect your lecturer for this, but infact tack it as a personal challenge to out do the lecturer, it will result in a much more productive result.

Chris