bugGNU Octave - Bugs: bug #57651, Second print command results in...

 
 

bug #57651: Second print command results in different marker size

Submitted by:  Rik <rik5>
Submitted on:  Tue 21 Jan 2020 11:16:07 PM UTC  
 
Category:  Octave Function Severity:  4 - Important
Priority:  5 - Normal Item Group:  Regression
Status:  Fixed Assigned to:  None
Originator Name:  Open/Closed:  Closed
Release:  dev Operating System:  Any

Add a New Comment (Rich Markup)
   

You are not logged in

Please log in, so followups can be emailed to you.

 

( Jump to the original submission)

Mon 17 Feb 2020 08:35:06 PM UTC, comment #11: 

I changed the default "paperposition" property to match the "papersize" and "position" properties.  This avoids requiring to change "paperpositionmode" from "auto" to "manual" and back to "auto" to force a re-calculation.  It also worked better in that I did not get segmentation faults when running bm_new_fig.m.

The changeset was made on stable here: https://hg.savannah.gnu.org/hgweb/octave/rev/5e79401cbc35.

Marking as fixed and closing report.

Rik <rik5>
Project Administrator
Tue 28 Jan 2020 04:21:35 PM UTC, comment #10: 

I remember trying to debug slow performance in the graphics engine several years ago and one of the big items was that the default values set up for graphics objects like axes were not quite correct.  This led the various listeners to fire and start an iterative process to determine the true size of the object.  Often the true size would be only 1 or 2 pixels different from the default size, but it would cost 100 milliseconds processor time to get to the true value.  It would be great for Octave's performance if we could prevent that cycle from happening.

Rik <rik5>
Project Administrator
Tue 28 Jan 2020 04:16:54 PM UTC, comment #9: 

The backtrace isn't very useful, at least to me, but here it is.

Thread 1 "octave-gui" received signal SIGSEGV, Segmentation fault.
0x00007ffff240207e in QMetaObject::invokeMethod(QObject*, char const*, Qt::ConnectionType, QGenericReturnArgument, QGenericArgument, QGenericArgument, QGenericArgument, QGenericArgument, QGenericArgument, QGenericArgument, QGenericArgument, QGenericArgument, QGenericArgument, QGenericArgument) () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
(gdb) bt
#0  0x00007ffff240207e in QMetaObject::invokeMethod(QObject*, char const*, Qt::ConnectionType, QGenericReturnArgument, QGenericArgument, QGenericArgument, QGenericArgument, QGenericArgument, QGenericArgument, QGenericArgument, QGenericArgument, QGenericArgument, QGenericArgument, QGenericArgument) () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#1  0x00007ffff79599a0 in QtHandles::ObjectProxy::finalize() ()
   from /home/rik/wip/Projects_Mine/octave-dbg/libgui/.libs/liboctgui.so.5
#2  0x00007ffff79599d1 in QtHandles::ObjectProxy::setObject(QtHandles::Object*) ()
   from /home/rik/wip/Projects_Mine/octave-dbg/libgui/.libs/liboctgui.so.5
#3  0x00007ffff798dfce in QtHandles::qt_graphics_toolkit::create_object(double) ()
   from /home/rik/wip/Projects_Mine/octave-dbg/libgui/.libs/liboctgui.so.5
#4  0x00007ffff241f1b2 in QObject::event(QEvent*) () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#5  0x00007ffff316d83c in QApplicationPrivate::notify_helper(QObject*, QEvent*) ()
   from /usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5
#6  0x00007ffff3175104 in QApplication::notify(QObject*, QEvent*) ()
   from /usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5
#7  0x00007ffff79edd56 in octave::octave_qapplication::notify(QObject*, QEvent*) ()
   from /home/rik/wip/Projects_Mine/octave-dbg/libgui/.libs/liboctgui.so.5
#8  0x00007ffff23ef9c8 in QCoreApplication::notifyInternal2(QObject*, QEvent*) ()
   from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#9  0x00007ffff23f213d in QCoreApplicationPrivate::sendPostedEvents(QObject*, int, QThreadData*) ()
   from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#10 0x00007ffff2449353 in ?? () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#11 0x00007fffeb258417 in g_main_context_dispatch () from /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
#12 0x00007fffeb258650 in ?? () from /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
#13 0x00007fffeb2586dc in g_main_context_iteration () from /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
#14 0x00007ffff244897f in QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) ()
   from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#15 0x00007ffff23ed9fa in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) ()
   from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#16 0x00007ffff23f6aa4 in QCoreApplication::exec() () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#17 0x00007ffff79f8d95 in octave::qt_application::execute() ()
   from /home/rik/wip/Projects_Mine/octave-dbg/libgui/.libs/liboctgui.so.5
#18 0x00005555555551ec in main ()

Rik <rik5>
Project Administrator
Mon 27 Jan 2020 10:08:28 AM UTC, comment #8: 

@Rik: Thanks for testing. This looks like 2 intricate issues:

  • The factory/default "paperposition" value does not match the one we should obtain when the "paperpositionmode" is "auto": so we need to update it.
  • The actual value  of the "position" property is subject to small changes of order 1 pixel: when the figure graphics_object is created, it is passed to the graphics toolkit which builds the actual figure window and changes the "position" property to match actual size of the onscreen window. This happens asynchronously and can cause small differences between the expected and obtained "paperposition" value. I can't find the bug report right now, but this is already reported.

I cannot reproduce the segfault with the patch. Can you attach a backtrace or does it not segfault when running under gdb?

Pantxo Diribarne <pantxo>
Project Member
Mon 27 Jan 2020 04:33:16 AM UTC, comment #7: 

@Pantxo: I tried to benchmark any slowdown from the proposed patch using

N = 20;

close all;

bm = zeros (N,1);
for i = 1:N
  tic;
  h = figure ();
  bm(i) = toc;
  close (h);
endfor

Instead, I got reasonably frequent segmentation faults.  I don't think this approach will work.

Next, I tried adding something equivalent to print.m

  if (strcmp (get (opts.figure, "PaperPositionMode"), "auto"))
    set (opts.figure, "PaperPositionMode", "manual");
    set (opts.figure, "PaperPositionMode", "auto");
  endif

However, this still produced a slightly different print out for the first time.  I tried various combinations of adding drawnow(), pause(), etc. and it is always a problem. 

I'm not sure how to proceed.  It works if I do something like

set (gcf, 'paperposition', [0, 0, 1, 2]);
set (gcf, 'paperpositionmode', 'auto');

but only when this occurs outside of print.m.

Rik <rik5>
Project Administrator
Thu 23 Jan 2020 07:49:12 PM UTC, comment #6: 

Yeah, you are right, the paperposition has to be updated manually since its default value differs from the one that we should have.

The following diff is not very elegant but does the trick:

diff -r eaca8df57328 libinterp/corefcn/graphics.in.h
--- a/libinterp/corefcn/graphics.in.h   Thu Jan 23 19:07:50 2020 +0000
+++ b/libinterp/corefcn/graphics.in.h   Thu Jan 23 20:47:51 2020 +0100
@@ -3262,6 +3262,13 @@
     // here, we just call its set function and let it decide which
     // properties from the list to use.
     obj.set_from_list (default_properties);
+
+    // Now make sure the paperposition is correct
+    if (xproperties.get ("paperpositionmode").string_value () == "auto")
+      {
+        xproperties.set ("paperpositionmode", "manual");
+        xproperties.set ("paperpositionmode", "auto");
+      }
   }

   void set (const caseless_str& name, const octave_value& value)

Pantxo Diribarne <pantxo>
Project Member
Wed 22 Jan 2020 10:12:27 PM UTC, comment #5: 

Different behavior on different machines?  This bug is going to be harder than I thought.  You can update the description if you are sure that the axes size is the only thing that really is different.

One thing I see is that the "paperposition" property is different between the first and second printings.  I can get both of the plots to be the same (in other words, both are wrong in that the markers overlap) by forcing an update of the paperposition property.

close all
graphics_toolkit qt
clf

h = plot (1:10, 'o-', 'markersize', 36);

## This forces re-calculation
set (gcf, 'paperposition', [0, 0, 1, 1]);
set (gcf, 'paperpositionmode', 'auto');

print -painters -color print1.ps
print -painters -color print2.ps

This probably says that there is a race condition, or that we should force a re-calculation of "paperposition" when printing and "paperpositionmode" is "auto".

Rik <rik5>
Project Administrator
Wed 22 Jan 2020 09:09:24 PM UTC, comment #4: 

I can reproduce the issue in comment #0 on machine 1, not on machine 2. I don't think this is about the marker size, but rather the actual figure (and axes) size at print time. Since we now set "auto" for the figure's "paperpositionmode", I would expect that the axes size in the ps file would match that in the onscreen figure.

  • Machine 1
    • print2.ps: the axes box is a bit larger than onscreen, but the text and the markers (fixed size objects) are magnified. The text being magnified is expected, this is a consequence of bug #45600. The marker is bug #57552.
    • print1.ps: the axes box is much larger than onscreen. The text and marker size are identical to print2.ps, but now, the axes being larger, the markers don't overlap anymore.
  • Machine 2: both figures look like print2.ps, and the axes size perfectly matches...

To summarize I get perfect results (neglecting the above bugs :-)) on machine 2, while on machine 1 I need to print twice to get acceptable result.

Can I update the the title to "Second print command results in different axes size"?

Pantxo Diribarne <pantxo>
Project Member
Tue 21 Jan 2020 11:32:24 PM UTC, comment #3: 

This bug is separate from bug #57552.  I temporarily hacked the scale factor to be 1.0 for markers and lines with the attached no_scale.diff.  The first plot still uses different sized markers from the second.

(file #48270)

Rik <rik5>
Project Administrator
Tue 21 Jan 2020 11:20:12 PM UTC, comment #2: 

This is not confined to just -painters generated output.  The same holds true for -opengl as I tested with

print -opengl -color print1.png
print -opengl -color print2.png

Rik <rik5>
Project Administrator
Tue 21 Jan 2020 11:17:35 PM UTC, comment #1: 

This may also related to bug #57552 where the markersize is incorrect for printing.

Rik <rik5>
Project Administrator
Tue 21 Jan 2020 11:16:07 PM UTC, original submission:  

The first and second print commands of the same figure result in different outputs.

Test code to reproduce error:

close all
graphics_toolkit qt
clf

h = plot (1:10, 'o-', 'markersize', 36);

print -painters -color print1.ps
print -painters -color print2.ps

In the first file, the 'o' markers seem to be about the correct size and do not overlap each other.  In the second file, the circular markers overlap.

The m-file and resulting output are attached.

Rik <rik5>
Project Administrator

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

Attached Files
file #48270:  no_scale.diff added by rik5 (1KiB - text/x-patch)
file #48267:  tst_first_print.m added by rik5 (144B - text/x-matlab)
file #48268:  print2.ps added by rik5 (177KiB - application/postscript)
file #48269:  print1.ps added by rik5 (177KiB - application/postscript)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by pantxo (Posted a comment)
  • -email is unavailable- added by rik5 (Submitted the item)
  • -email is unavailable- added by rik5
  •  

    Do you think this task is very important?
    If so, you can add your encouragement to it.
    This task has 0 encouragements so far.

    Only project members can vote.

     

     

     

    Follow 7 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2020-02-17 rik5 StatusConfirmed => Fixed
        Open/ClosedOpen => Closed
    2020-01-21 rik5 Attached File- => Added no_scale.diff, #48270
    2020-01-21 rik5 Attached File- => Added tst_first_print.m, #48267
        Attached File- => Added print2.ps, #48268
        Attached File- => Added print1.ps, #48269
        Carbon-Copy- => Added pantxo

    Back to the top


    Powered by Savane 3.5