octave-maintainers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: circular markersizes via rotation matrix


From: Daniel J Sebald
Subject: Re: circular markersizes via rotation matrix
Date: Fri, 19 Aug 2016 16:55:33 -0500
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2

On 08/19/2016 04:22 PM, Rik wrote:
8/19/16

Dan,

I benchmarked the current code for creating circular markers ("o") using
either the current method relying on trigonometry and sin()/cos() function
calls or via the rotation matrix that you coded which only uses
multiplications and additions.  The short story is that I didn't find any
significant difference so I left the code as is.

That's similar to what I had found. I ran your scripts here and saw no difference as well. The issue, I think, is that the rendering routine for the circles is a tiny fraction of the cpu consumed elsewhere. My guess is that the creation of the properties associated with each new "plot()" call consumes a lot of CPU. There is clearing old memory, mallocing new memory, initializing all the properties, etc. The OpenGL code, too, is probably considerable.

I think if we want to test the efficiency of using trig functions all the way around the circle versus using matrix rotations, we'd probably have to write a very simple C++ test routine and basically just do the computations for, say, 5000000 circles and see which versions runs faster. One doesn't even have to call any OpenGL code for that. It's the same number of points--it's only the way they are computed that is different.

Or, maybe another crude way is to draw 50000 circles on a plot:

graphics_toolkit ('qt')
plot(rand(50000,1),rand(50000,1), 'o');

and drag the window corner around to see how responsive the redraw is.

I actually like the C-program idea. It wouldn't be but a twenty to thirty line program. If I find time late tonight I'll do that.

Will it matter in the bigger picture?  Not much.

Dan



reply via email to

[Prev in Thread] Current Thread [Next in Thread]