bugGNU Octave - Bugs: bug #62101, graphics properties broken with...

 
 

bug #62101: graphics properties broken with gnuplot backend

Submitter:  Sébastien Villemot <svillemot>
Submitted:  Wed 23 Feb 2022 01:36:01 PM UTC
 
Category:  Plotting with gnuplot Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Regression
Status:  None Assigned to:  None
Originator Name:  Open/Closed:  * Open
Release:  * dev Operating System:  * Any
* Mandatory Fields

Add a New Comment (Rich Markup)
   

Comment Type & Canned Response:
       

 

( Jump to the original submission )

Thu 02 Jun 2022 12:08:15 PM UTC, comment #10: 

Changing the release target to "dev" because any changes for this issue are likely to go on the default branch. (That is if someone feels like spending their time on the gnuplot graphics interface at all.)

Markus Mützel <mmuetzel>
Project Member
Thu 03 Mar 2022 06:19:41 PM UTC, comment #9: 

@sébastien: I agree with Rik that an actual list of issues preventing people from using Octave's default toolkit for producing publication quality figures would help much. I may not be as intransigent or my use case may not be as demanding as others (e.g. in practice I very seldom use 3D plots) but I do use directly Qt to produce my figures for publication and courses.

Pantxo Diribarne <pantxo>
Project Member
Thu 24 Feb 2022 04:13:06 PM UTC, comment #8: 

I agree, probably a separate discussion about the future of Qt graphics in Octave.  It would be interesting to know what the principal problems are with using Qt for publication-quality plots so that they could be addressed.  If it is text quality, rather than graphics quality, then the print options that go through Latex are useful.

Rik <rik5>
Project Administrator
Thu 24 Feb 2022 03:49:42 PM UTC, comment #7: 

We are getting off track, but I must say that gnuplot with cairo
based terminals (qt, png-cairo, pdf-cairo) are superior to current octave graphics. For publication-quality plots i save data to a text file and use straight gnuplot for the actual plots.

Dmitri.
--

Dmitri A. Sergatskov <dasergatskov>
Thu 24 Feb 2022 03:29:32 PM UTC, comment #6: 

Given the long term lack of support for gnuplot, it might still be better to think of segregating computation on to headless servers and then performing the final display / plotting on a machine with Qt.  I find that the graphics produced by gnuplot, even when accurate, to be rather ugly and wouldn't choose that solution even without the complication of remote servers.

Rik <rik5>
Project Administrator
Thu 24 Feb 2022 02:05:35 PM UTC, comment #5: 

Thanks Dmitri, I had somehow overlooked this.

Sébastien Villemot <svillemot>
Thu 24 Feb 2022 01:50:33 PM UTC, comment #4: 

FWIW:

xvfb-run --help
Usage: xvfb-run [OPTION ...] COMMAND
Run COMMAND (usually an X client) in a virtual X server environment.
Options:
-a        --auto-servernum          try to get a free server number, starting at
                                    --server-num (deprecated, use --auto-display
                                    instead)
-d        --auto-display            use the X server to find a display number
                                    automatically

seems to work for octave's buildbots.

Dmitri.
--

Dmitri A. Sergatskov <dasergatskov>
Thu 24 Feb 2022 10:21:52 AM UTC, comment #3: 

I’ve tried to use xvfb-run as a replacement but unfortunately it does not play well with parallelization, because by default all Xvfb servers want to use the same number (99). It’s probably possible to engineer a solution that generates different server numbers from a parallelized makefile, but that’s not trivial.

More generally, it would be much better if Octave had a reliable internal solution for working on headless systems (and incidentally, note that Xvfb relies on the X protocol, which is a dying technology).

I understand that developers don’t have the motivation to work on the gnuplot backend, but in practice that implies a regression in functionality.

Sébastien Villemot <svillemot>
Thu 24 Feb 2022 01:14:03 AM UTC, comment #2: 

Presumably this can work, since it did in 6.4.  However, someone would need to be motivated to debug the code.  The core developers rarely have the time for gnuplot-related bugs.

Since the error message is quite specific it might be easy to trace and find the problem by issuing

debug_on_error (1)

before executing the problematic code.

Rik <rik5>
Project Administrator
Wed 23 Feb 2022 07:31:02 PM UTC, comment #1: 

Like you wrote, the "gnuplot" graphics toolkit is deprecated and will likely be removed at some point in the future (given that it is likely that more and more issues like this one will probably creep in in the future). Patches for it are still welcome though.

With that in mind, you could check if it is possible to use virtual frame buffers (like `xvfb`) to allow "more modern" graphics toolkits like "qt" on headless systems. That is working quite well for us in our CI.

Markus Mützel <mmuetzel>
Project Member
Wed 23 Feb 2022 01:36:01 PM UTC, original submission:  

Hi,

Consider this snippet:

h = figure;
hbar = bar(rand(10, 3),'FaceColor','flat');
set(hbar,'edgecolor','flat');
refresh(h);

When run under Octave 7.0.90 with the --no-window-system option (which implies the gnuplot backend), one gets:

error: ccol(1): out of bound 0 (dimensions are 0x0)
error: called from
    __gnuplot_draw_axes__ at line 1162 column 34
    __gnuplot_draw_figure__ at line 169 column 17
    __gnuplot_drawnow__ at line 91 column 5
    refresh at line 47 column 3
    glou at line 4 column 1

This error is related to the set(hbar,'edgecolor','flat') command.

And when that command is removed, there is no crash but one gets gnuplot errors and the resulting graphics is incorrect. This second problem disappears when one removes the 'FaceColor', 'flat' graphics properties.

These issues are regressions, since they do not occur with Octave 6.4.0.

I’m aware that the gnuplot backend is deprecated, but it’s the default when --no-window-system is given (and it’s very useful to be able to generate graphics without a display, e.g. when running testsuites on continuous integration platforms as we do for Dynare).

Sébastien Villemot <svillemot>

 

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

Attach Files:
   
   
Comment:
   

No files currently attached

 

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 dasergatskov (Posted a comment)
  • -email is unavailable- added by rik5 (Posted a comment)
  • -email is unavailable- added by mmuetzel (Posted a comment)
  • -email is unavailable- added by svillemot (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only project members can vote.

     

     

     

     

    Follows 1 latest change.

    Date Changed by Updated Field Previous Value => Replaced by
    2022-06-02 mmuetzel Release7.0.90 dev

    Back to the top


    Powered by Savane 3.9