Er... is StrictMath already FPU accelerated? If it
is then, oh well...
Its as far accalerated as the FPU produces acceptable results.
For example on x86 the sin-command is used only in a special range where its
known to be correct.
The current Math package is really not very good.
A better optimized solution would be to look up for
the right color in setRGB depending on the angle of
the currently drawn pixel - this way you draw the
circle only once, altering the color is bascially
free :)
I modified the setRGB() method of your program as follows to get my optimized
Is there an alternate, faster way to do the maths?
The problem here is Math.round and Math.atan2, the Math class is optimized for
high precission but often sacrifices speed.
Your original version took 205ms on my C2D, replacing atan2 with this unprecise
version and removing the round braught
YES! Why not FPU acceleration? That's what it's there for.
Er... is StrictMath already FPU accelerated? If it is then, oh well...
The current Math package is really not very good. Especially
for low level graphics stuff where 5 significant digits is
the minimum accuracy that is useful.
I don't modify the Graphics2D default stroke value, so I assume that the arcs
are 1 pixel wide.
[Message sent by forum member 'ser207' (ser207)]
http://forums.java.net/jive/thread.jspa?messageID=301250
===
To unsubscribe,
Ig thanks for your reply. I'm amazed by how much quicker your method is
compared to g2d.draw( Ellipse2D)); There is a MASSIVE difference.
I have tried to adapt your solution to draw arcs; i've googled but have not
been able to find an arcs algorithm that I can use (at least not one that
this thing is called midpoint circle algoyrthm.
There is also a version which draws the circly only in a defined angle, I was
not able to find such a version with a quick look at search machines, but I
think there are definitivly ready-to-use implementations available.
A better optimized
this thing is called midpoint circle algoyrthm.
Yes after my previous post I found this:
http://en.wikipedia.org/wiki/Midpoint_circle_algorithm
Which led me to hack your version of the waterfall code to do arcs.
Unfortunately I don't think it is accurate for small angles, for example less
than
Well, this seems really hard to optimize ... tons of very small primitives.
The only advice I can give you is to grab the Raster of a INT_RGB buffered
image:
byte[] data=((DataBufferByte)tex.getRaster().getDataBuffer()).getData() (in
your case its an int[] of course), and write code that does
In other words each new arc is effectively underneath all of the
previous arcs?
You could use intermediate images for this.
Create 2 INT_ARGB images the size of your drawing (or the portion with
this waterfall-ish effect). On each frame you have the one that holds
all of the previous arcs
In other words each new arc is effectively
underneath all of the
previous arcs?
No, the opposite. Each new arc needs to be painted on the outside/on top, the
previous arcs are 'effectively' pushed in towards the center.In any case I
like your proposal.
Another observation from the
Are these 1-pixel wide arcs or wider?
Currently we have 2 different paths for drawArc. If we determine that
the stroke size is less than or equal to a pixel then we trace along
the arc and use a bresenham-like algorithm to touch the pixels. If it
is wider then we invoke a line widening
Hi again,
It does not draw segments but I guess it should be easily extendable to do so -
its late and I'll go to bed now instead of playing any further. Btw. it does
500 lines in 12ms on my C2D.
Did not think about the gradient solution, sounds really good :)
[code]
package waterfall;
13 matches
Mail list logo
