n romaai

Greenhorn
+ Follow
since Mar 18, 2011
Merit badge: grant badges
For More
Cows and Likes
Cows
Total received
0
In last 30 days
0
Total given
0
Likes
Total received
0
Received in last 30 days
0
Total given
1
Given in last 30 days
0
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by n romaai

So using a SwingWorker to call repaint

Thanks for the tip about the name 'Main'

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.

11 years ago
Okay, You guys are saying to do this:

Now what?
11 years ago

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?
11 years ago
Also, why would moving the mouse over the panel smoothen the animation?
12 years ago
Actually, lets make sizestep = .0005.
So the question is, without changing the sizestep, is there a way to make the animation go faster?
12 years ago
For all you non-clairvoyant

12 years ago
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
12 years ago
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
12 years ago
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.

Any ideas?
12 years ago
what I said is:

until the outer, buffered outputstream is flushed

only then does the inner, file outputStream

see the bytes coming in

so,

the outer bufferedOutputStream keeps

- or prevents -

the bytes from being written to the inner fileOutputStream

13 years ago
Actually, that does not seem true.



Results:



On CentOS 5
It seems the fileOutputStream does not update position until the outer outputStream is flushed
13 years ago
@Stephan van Hulst

Thanks, you answered my question.

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() ?
13 years ago
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
13 years ago