I'll fix this temporarily with the call to get.  Given that set_linewidth is called tens of times even for simple plots I think it would be a good idea to move the overall conversion factor in to a member variable (like m_devpixratio) that is calculated only once, or when the screen changes.

In that vein, I would also store the single conversion factor so that instead of two multiplications per call

width = w * points2pixels * m_devpixratio;

there would just be one

width = w * m_linewidth_factor;

@Pantxo: Could you review this patch?  Conceptually, it is correct.  In order to change the LineWidth measured in points, to one measured in pixels for glLineWidth, one only needs to multiply by a conversion factor.  This conversion factor is the monitor's pixels per inch divided by the factor 72 points/inch.

-    m_glfcns.glLineWidth (w * m_devpixratio);
+    float points2pixels = toolkit.get_screen_resolution () / 72.0;
+    m_glfcns.glLineWidth (w * points2pixels * m_devpixratio);

The problem is that the code doesn't work because toolkit.get_screen_resolution always returns 72.  It is declared as a virtual function graphics-toolkit.h and is meant to be overloaded by _init_fltk_, _init_gnuplot_, or _init_qt_.  Unfortunately, they don't seem to do that, or they overload it by just returning the constant 72 without checking the actual monitor resolution.

This information is, somehow, available because

get (0, 'screenpixelsperinch')

returns a value on my system which is close to 96.  The root object's value is initialized in graphics.cc by this function.

default_screenpixelsperinch (void)
{
  return (octave::display_info::x_dpi () + octave::display_info::y_dpi ()) / 2;
}

Earlier I tested my patch by hardcoding the screen resolution at 96 so I know that it is only get_screen_resolution which is not working.



(file #46232)

@Michael: The screenshot you attached turns out to be the m-file tst_lwidth3.m.  Could you re-post?

@Michael: The tests showed that the print outs have nearly the same width (Octave is always exactly 1 pixel larger than Matlab).

However, the on-screen display does seem off.  Could you try my latest test script, tst_lwidth3.m, which is attached.  It disables anti-aliasing so I can get a true idea of the line width.  Also, you will need to do a window screen capture, rather than a print, to capture the data since the print code path is different and we have already verified that it works.

(file #43201)

The sizes are definitely different.  It's my mistake on the error message since I never use Matlab and guess at their syntax.  I updated the m-file after reading their documentation more closely.  Could you try the new m-file and see if it is able to generate the png file from print?



(file #43168)

According to Matlab documentation, LineWidth and MarkerSize for line objects are specified in points.  In Octave, we use the OpenGL function glLineWidth which sets line width in pixels.

Given that Matlab interprets pixels to mean 1/96 of an inch and points are defined to be 1/72 of an inch, this should mean that Octave merely needs to inflate sizes by 96/72 == 4/3.

In order to test this, could someone try the following script in Matlab (also attached) and upload the resulting file?

close all
ver   % Show what version is running
h1 = line ([0 1], [0.1 0.1], 'linewidth', 0.5);
h2 = line ([0 1], [0.2 0.2], 'linewidth', 1);
h3 = line ([0 1], [0.3 0.3], 'linewidth', 2);
h4 = line ([0 1], [0.4 0.4], 'linewidth', 2.75);
h5 = line ([0 1], [0.5 0.5], 'linewidth', 3);
h6 = line ([0 1], [0.6 0.6], 'linewidth', 6);
h7 = line ([0 1], [0.7 0.7], 'linewidth', 12);
h8 = line ([0 1], [0.8 0.8], 'linewidth', 18);
ylim ([0 1]);
print -r300 lwidth.png