never override paint(..) in Swing, use paintComponent(..),
and the first line generally is super.paintComponent(..);
Are you sure?
From JavaDocs Subclasses can just override this method, as always. A subclass that just wants to specialize the UI (look and feel) delegate's paint method should just override paintComponent.
Michael Dunn wrote:Honestly, the code is terrible. Read the link for the correct way of painting in Swing.
Can you be more specific or can you just paste a link to a tutorial? I mean, thanks for saving me the trouble of searching and clicking on a link.
Also, whether the code is terrible or not is not the original question. The original question pertains to the code in the paint method of the Visual.
Is there a way to make it go faster without just changing sizestep?
Also, on Debian 6, moving the mouse over the window smoothens the animation. Why?
Actually, Its looking better on my Win Vista box that has much more mem and two better processors. But I'd still be very interested in some tips to the original question. Shirley, theres a software approach to the question
Well, I want the animation to go faster without making it step more, so it stays smooth. Im basically drawing a circle that grows in size, so instead of making the radius increase by a greater amount, which makes it choppily grow in size, I want it to be a smooth trnansition, but I want the whole thing to happen faster. I want it to go faster than it is but I dont want to sacrifice smoothness
On my debian laptop, Moving the mouse over the JPanel in the JFrame seems to smoothen the animation in the JPanel. Can anybody give insight as to why this might happen?
Also, is there a way to smoothen the animation programmatically? Should I try double buffering or is there other things I can try too?
I want the animation to happen faster, but I still want all intermediate values, so it wont look choppy. Increasing the frame rate makes it smoother not faster, but like I said I dont want to make each step bigger.
I kinda figured that I could rely on the correctness of position() and its consistency across storing the fileChannel instance but got worried when I saw the documentation for OutputStream.flush()
It sounds like any discrepancy is way in the operating system, like, transparent even to the VM...
The documentation is probably just being thorough for implementations of OutputStream
plus now I dont have to try to track number of bytes "written" myself
would I even have to flush the outer bufferedOutputStream to see the correct position() ?
Im writing to a BufferedOutputStream( FileOutputStream ) and I want to occasionly record the position that the file stream is at.
the bytes may not be written to file at the time flush is completed (from the documentation for OutputStream.flush)
so, does this mean the position I get from theChannel.position() might not represent all the bytes written so far?
Im also trying to keep the channel instance separately, but I guess I dont have to.
Will only the fileChannel returned from fos.getChannel have the current position?
In other words, if I store fileChannel instance, then write to the underlying fileOutputStream,
will the old fileChannel instance see that change?
calling position on the old instance will give the position correctly with the intervening write call?
Does anybody know how much I can rely on this?
I just wanted to ask and see before I spent a lot of time googling and experimenting