[Octave-bug-tracker] [bug #48208] "markersize" compatibility

[Rik]

Update of bug #48208 (project octave):

              Item Group:       Inaccurate Result => Matlab Compatibility   
                 Summary: "markeredgecolor" changes symbol color instead when
symbol is '.' => "markersize" compatibility

    _______________________________________________________

Follow-up Comment #5:

Thanks everyone for testing.  The supposed behavior for a primitive line
object is found at
http://www.mathworks.com/help/matlab/ref/primitiveline-properties.html.

I mispelled the attribute 'markeredgecolor' which is why this error resulted.


get (h, 'markeredegcolor') % What is default (blue, or something else)
Error using graph2d.lineseries/get
The name 'markeredegcolor' is not an accessible property for an instance of
class
'lineseries'. 


That's okay though.  I get the gist, which is that for '.' the 'Color'
attribute is used, unless 'markeredgecolor' has been specified to a different
value than 'auto'.  So Octave is okay in that respect.

But I don't understand the sizings.  According to the documentation the sizing
is done in points (basically 1/72 of an inch).  So for a screen resolution of
90 ppi I would expect some relation to the quantity


pixel_size = marker_size (points) * 1 inch     * 90 pixels
                                    ------       ---------
                                    72 points       inch


In gl-render.cc I see the following code for the marker size.


  double sz = size * toolkit.get_screen_resolution () / 72.0;


and later


    case '.':
      {
        double ang_step = M_PI / 5;

        glBegin (GL_POLYGON);
        for (double ang = 0; ang < (2*M_PI); ang += ang_step)
          glVertex2d (sz*cos (ang)/3, sz*sin (ang)/3);
        glEnd ();
      }


But also,


    case 'o':
      {
        double ang_step = M_PI / 5;

        glBegin ((filled ? GL_POLYGON : GL_LINE_LOOP));
        for (double ang = 0; ang < (2*M_PI); ang += ang_step)
          glVertex2d (sz*cos (ang)/2, sz*sin (ang)/2);
        glEnd ();
      }


So, for the 'o' marker everything makes sense.  The size (diameter) is
determined in points.  And the draw routine uses diameter/2, or the radius, to
construct the 'o'.  But the dot marker is special.  It is using diameter/3 for
the radius. 
@Lachlan: Could you run tests in Matlab to try and determine what is going on?
 I think we need to construct a table of marker size versus resulting pixel
size on screen.

Possible code, with measurement after each run:


h = plot (0.5, 0.5, '.k');
set (h, 'markersize', 0.5); 
set (h, 'markersize', 1); 
set (h, 'markersize', 2); 
set (h, 'markersize', 3); 
set (h, 'markersize', 4); 
set (h, 'markersize', 5); 
set (h, 'markersize', 6);   % This is the default
set (h, 'markersize', 8); 
set (h, 'markersize', 12); 
set (h, 'markersize', 16); 
set (h, 'markersize', 20); 
set (h, 'markersize', 24); 
set (h, 'markersize', 32); 
set (h, 'markersize', 36); 
set (h, 'markersize', 48); 
set (h, 'markersize', 72); 


And then repeated with the 'o' marker.


h = plot (0.5, 0.5, 'ok');
set (h, 'markersize', 0.5); 
set (h, 'markersize', 1); 
set (h, 'markersize', 2); 
set (h, 'markersize', 3); 
set (h, 'markersize', 4); 
set (h, 'markersize', 5); 
set (h, 'markersize', 6);   % This is the default
set (h, 'markersize', 8); 
set (h, 'markersize', 12); 
set (h, 'markersize', 16); 
set (h, 'markersize', 20); 
set (h, 'markersize', 24); 
set (h, 'markersize', 32); 
set (h, 'markersize', 36); 
set (h, 'markersize', 48); 
set (h, 'markersize', 72); 


At the large sizes, like 72, it is clear that Octave is actually drawing
10-sided decagons, rather than smooth circles.  Does Matlab do this to or do
they scale the number of vertices in the OpenGL polygon to make it appear
smooth at all sizes?


    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?48208>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/