[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: |
Sat, 20 Aug 2016 15:34:07 -0500 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 |
On 08/20/2016 12:39 PM, Daniel J Sebald wrote:
On 08/19/2016 06:03 PM, Dmitri A. Sergatskov wrote:
On Fri, Aug 19, 2016 at 4:22 PM, Rik <address@hidden
<mailto:address@hidden>> wrote:
-- Benchmark # 1 --
N = 128;
bm = zeros (N, 1);
clf;
for i = 1:N
tic;
plot (1:10, "o", "markersize", N);
bm(i) = toc;
endfor
mean (bm)
-- End Benchmark # 1 --
I tried this benchmark for "o", ".", "x", and "*" symbols and N=1280.
All results were pretty much the same (0.0175). Which pretty much tells
me that
the most of the time spent elsewhere (not calculating the symbol shape).
Correct. For what it's worth, here's a C program to illustrate the
difference. I think it is a apples-to-apples comparison, and it seems
about right in terms of what goes into computing a sinusoidal value. For
one million circle computations, I'm seeing:
sebald@ ~/octave/nontrig_circle_symbol $ ./testcircle
sz=12 div=3 alg=trig
real 0m1.393s
user 0m1.392s
sys 0m0.000s
sz=100 div=27 alg=trig
real 0m6.185s
user 0m6.180s
sys 0m0.000s
sz=12 div=3 alg=matrot
real 0m0.113s
user 0m0.112s
sys 0m0.000s
sz=100 div=27 alg=matrot
real 0m0.382s
user 0m0.380s
sys 0m0.000s
Something didn't make sense to me (i.e., the fact it takes 6.185s to
compute coordinates for 1M circles, yet that is almost as long as it
takes for the first pass of the OpenGL rendering for 1M 'or' symbols).
Also, note how quickly an OpenGL rendering of a 1M points takes, just a
fraction of a second.
So I put some fprintf's in the code. Now I see why the
trig/matrix-rotation business makes no difference at all: That code is
only used twice to construct the non-filled and filled circle marker
prototypes, it's not used for every circle symbol. The code we've been
looking at is only used for constructing a list of symbols kept internal
to OpenGL. Then we have:
for (int i = 0; i < n; i++)
{
if (clip[i] == clip_ok)
draw_marker (x(i), y(i),
has_z ? z(i) : 0.0,
lc, fc);
}
and draw_marker is expanded as:
opengl_renderer::draw_marker (double x, double y, double z,
const Matrix& lc, const Matrix& fc)
{
#if defined (HAVE_OPENGL)
ColumnVector tmp = xform.transform (x, y, z, false);
glLoadIdentity ();
glTranslated (tmp(0), tmp(1), -tmp(2));
if (filled_marker_id > 0 && fc.numel () > 0)
{
glColor3dv (fc.data ());
set_polygon_offset (true, -1.0);
glCallList (filled_marker_id);
if (lc.numel () > 0)
{
glColor3dv (lc.data ());
glPolygonMode (GL_FRONT_AND_BACK, GL_LINE);
glEdgeFlag (GL_TRUE);
set_polygon_offset (true, -2.0);
glCallList (filled_marker_id);
glPolygonMode (GL_FRONT_AND_BACK, GL_FILL);
}
set_polygon_offset (false);
}
else if (marker_id > 0 && lc.numel () > 0)
{
glColor3dv (lc.data ());
glCallList (marker_id);
}
Rik, I wonder how efficient this glColor3dv() routine is and whether it
needs to be called for each marker. Maybe if this generic singular
"draw_marker" were replaced with a "draw_marker_array" function the
marker drawing could be sped up some.
Dan