bugGNU Octave - Bugs: bug #59370, Better document limitations of...

 
 

bug #59370: Better document limitations of gnuplot graphics toolkit

Submitter:  T Knauss <tknauss>
Submitted:  Tue 27 Oct 2020 04:45:04 PM UTC
   
 
Category:  Plotting with gnuplot Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Documentation
Status:  Fixed Assigned to:  None
Originator Name:  Open/Closed:  * Closed
Release:  * 6.0.92 Operating System:  * Any
Fixed Release:  None Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Thu 05 Nov 2020 12:14:41 PM UTC, comment #16: 

I opened bug #59418 to track improving the documentation by adding known work-arounds for plotting data that scales badly in single-precision floating point accuracy when using OpenGL graphics toolkits.

Closing this report as fixed.

Markus Mützel <mmuetzel>
Group administrator
Fri 30 Oct 2020 04:06:40 PM UTC, comment #15: 

I reviewed the proposed patch for the documentation, made a few changes, and checked it in here http://hg.savannah.gnu.org/hgweb/octave/rev/16b14c431348.

Marking as Ready for Test.

Whether as part of this issue report, or a separate one, I think we should add a @subsection or @subsubsection with workarounds for the OpenGL toolkit.  The qt toolkit remains the preferred toolkit, and there are specific strategies for dealing with either large values which exceed the range of a single type or for data with very fine gradiations which exceeds the resolution of a single type.

Rik <rik5>
Group administrator
Fri 30 Oct 2020 01:18:35 PM UTC, comment #14: 

T Knauss:  I appreciate that you are taking the time to provide bug reports and feedback.  But we are all just volunteer contributors here.

Maybe it is just a cultural or language difference, but I find it best to avoid phrases like "you need to do X" or "you should do Y" when discussing issues with people who are volunteering their time.

We often change the summary and other info like the category, item group, release, or operating system in existing bug reports when it turns out they are incorrect or incomplete.  I don't see a problem with that.

John W. Eaton <jwe>
Group administrator
Fri 30 Oct 2020 12:59:20 PM UTC, comment #13: 

Please, see the attached patch for a possible change of the documentation.

Could a native speaker please review the language if we want to make that change on stable?

(file #50167)

Markus Mützel <mmuetzel>
Group administrator
Fri 30 Oct 2020 11:21:27 AM UTC, comment #12: 

I would never change an existing report, because it describes a problem and the way towards a possible solution. By changing the title you remove the possibility for others to find the solution to  a similar problem. If s.o. else now searches for problems on plotting, they will not find this issue and don't see that it's just a matter of bad documentation. Because of that, I would have kept this report as is and open a new one, so this report itself could already have served as documentation in some way.

I would help improving Octave if I had time for it, but unfortunately this is not the case. But at least I write bug reports, which most other users don't do. And I did not demand anything, I just wrote what the logical consequences would be in my opinion.

T Knauss <tknauss>
Fri 30 Oct 2020 08:29:38 AM UTC, comment #11: 

You identified yourself that this bug report was caused by incomplete documentation. So I don't think we need to open a new report.

Btw, GNU Octave is free software that is developed by volunteers. You are welcome to help improve Octave (either by providing patches for issues you feel are important or by paying a developer to fix them). But I feel like it is undue to demand deadlines to fix issues like you did.

Markus Mützel <mmuetzel>
Group administrator
Fri 30 Oct 2020 08:20:09 AM UTC, comment #10: 

This bug report originally was about
- the wrong display of data in figures (obviously caused by the single precision value processing in qt and fltk), which seems to be addressed in another issue already,
- and the high CPU usage and delays (partly caused by wrong programming - "close" missing -, due to incomplete documentation).

If you say that gnuplot is deprecated and has lots of issues, and if you find that fixing these issues is not worth the time needed, then you should remove it in the next version of Octave. But you need to improve the qt and fltk first to use double precision floating point arithmetic. Gnuplot at least produced a correct result, so if you decide to keep it, then you definitely need to improve the documentation.

I vote to close this issue, since everything I reported seems to be a duplicate of something else.
If you think you should create another one for improving the docs, then you may do so, but I would not change existing issues.

T Knauss <tknauss>
Thu 29 Oct 2020 09:41:56 PM UTC, comment #9: 

Just to correct one misstatement on this bug report, you can change the toolkit used by an existing figure.  Try 'help graphics_toolkit' for the syntax to do so.

But, this bug report seems to be about issues with the gnuplot toolkit.  These are widely known and is why qt is the preferred graphics toolkit and also why no new development, only the occasional bug fix, is being done for gnuplot.

If you have any choice, and the MS Windows version of Octave does include it, you should use the qt toolkit.

@Markus: Should this bug be re-titled to be about documenting the nature of the gnuplot toolkit (one-way pipe) and thus some of its failings (slow, closing windows isn't reflected in Octave, etc.)

Rik <rik5>
Group administrator
Wed 28 Oct 2020 09:30:07 PM UTC, comment #8: 

comment #7:

> ...
> Using the commands you showed so far, I was not able to reproduce the high CPU usage and long delay you describe.
> Could you please provide the exact steps that trigger the slowness for you?
>


That's really easy for me:
1) start Octave GUI
2) graphics_toolkit ("gnuplot")
3) S=[0.966087204808546, 0.966087204808546, 0.966087204808546, 0.966087217807083, 0.966087217807083]
4) plot (S)
5) close the just opened figure by clicking on the red x in the top right corner of that window (this means, close that window manually using the mouse)
6) plot (S)
I get a 10 seconds 12.5% CPU usage (100% on one CPU core).
7) close again, like in 5)
8) plot (S), like in 6)
Again 12.5% CPU usage, this time for 23 seconds.
9) close again, like in 5)
10) plot (S), like in 6)
This time, the window was shown instantly.

The next delays were 23s, 0s, 0s, 23s, 23s.
And, curiously, the figure window that was shown after a delay became bigger and bigger each time, until it reached fullscreen after the 4th delayed opening. The other windows, which were opened after no delay, were opened in normal size.
From the 5th high-CPU call on, no window was shown anymore.

When finally calling "close all", I could restart the whole behaviour, but partly with different delays.
After restarting Octave GUI, I could restart the behvaiour with the SAME delays.

Also, I want to add that some figures where shown without any content in the graph area. Only window with toolbar and status bar was shown, the graph appeared when clicking on the zoom+.

T Knauss <tknauss>
Wed 28 Oct 2020 06:55:58 PM UTC, comment #7: 

It is perfectly fine to deliberately create three figures at the same time, each using a different graphics toolkit.
I don't know why that should be prevented.

Only the interface to gnuplot is "one-way". The other two graphics toolkit are "part" of Octave. But I agree that this could probably be better documented. (A good place for this might be section "15.1 Introduction to Plotting" of the manual.)

The interface to gnuplot really is one-way. There is no way to check whether a reusable figure exists.

Using the commands you showed so far, I was not able to reproduce the high CPU usage and long delay you describe.
Could you please provide the exact steps that trigger the slowness for you?

Markus Mützel <mmuetzel>
Group administrator
Wed 28 Oct 2020 06:38:25 PM UTC, comment #6: 

comment #5:

> ...
> From what you describe, I guess you are accidentally re-using the gnuplot figure after you changed to a different graphics toolkit.
>
> Since commands to gnuplot are sent using a pipe, this can be slow, especially when drawing lots of objects. Also it might take some time for gnuplot to load when you first use it.
> Plotting the simple line from comment #0 should be fast though.
>
> Is that consistent with what you observe?


Yes, your guess is correct. When I use "close all" before the next "plot (S)", the plot is shown immediately and neither a delay nor high CPU usage occur. I didn't know that closing the figures manually or via command makes a difference, and I bet that many other people also don't know that. They just don't notice, because they never change the graphics toolkit.

This shows that there is room for improvements: When switching the graphics toolkit, all existing figures should be closed by the switching method, because they cannot be reused with the new toolkit anyway. Not closing the figures and deleting all handles from the previous toolkit should actually be treated as a bug in my opinion.

But, even when staying with gnuplot, if the "plot" command is called multiple times without "close" in between, the plotting method (in gnuplot) should not cause such a high CPU usage and long delay. It should check whether a reusable figure exists, and if not, close orphaned figures and handles before creating a new one. There is no such problem in "qt" and "fltk".

T Knauss <tknauss>
Wed 28 Oct 2020 03:41:11 PM UTC, comment #5: 

In contrast to the other graphics toolkits, gnuplot is a separate program.
The link from Octave to gnuplot is a one-way pipe. So, Octave has no way of knowing whether a gnuplot figure was closed (or resized or whatever...).
The graphics toolkit of an existing figure cannot be changed after it is created.
When you change from gnuplot to a different graphics toolkit, you have to close the gnuplot figure explicitly (either with `close (figure_handle)` or with `close all`). Closing the figure alone does not help.

From what you describe, I guess you are accidentally re-using the gnuplot figure after you changed to a different graphics toolkit.

Since commands to gnuplot are sent using a pipe, this can be slow, especially when drawing lots of objects. Also it might take some time for gnuplot to load when you first use it.
Plotting the simple line from comment #0 should be fast though.

Is that consistent with what you observe?

Markus Mützel <mmuetzel>
Group administrator
Wed 28 Oct 2020 09:32:19 AM UTC, comment #4: 

Update: Due to the weird behaviour when switching graphics toolkits, and due to the contrary behaviour of "fltk" to other people's tests and its implementation, I tested again.
This time I switched to "fltk" as first step, directly after opening Octave GUI. Then I created S and called "plot(S)". The plot was incomplete in the same way as in the screenshot attached to the original post.

My conclusion: It looks like there are serious issues when switching the graphics toolkit. These issues seem to affect performance and output. Most likely there is no proper cleanup routine, or the switching itself does not work correctly and maybe forgets important initialization steps.

The performance issues persist, without an obvious pattern. Some plots are shown immediately, some take 10 to 20 seconds.
As long as I use the default graphics tookit ("qt"), no delay is seen. The delays come up after switching the graphics toolkit.

T Knauss <tknauss>
Tue 27 Oct 2020 08:17:52 PM UTC, comment #3: 

On linux, all I can reproduce is the known part of the bug. Since OpenGL toolkits both only handle single precision floating point numbers, the plot command fails baddly (see printout below): this looks like bug #32980 or some flavor of it (bug #36094).
The strange thing is that it works for you with fltk...

You can workaround it by scaling your data, e.g :


...
plot ((S - mean (S)) / (max (S) - min (S)))


As for gnuplot, it produces the right output instantly and doesn't trigger any intensive cpu load.

I'll change the category to "Plotting with Gnuplot", since the OpenGL part of the bug is already tracked elsewhere. I'll also change the Item group to performance since you report a long time lag and high cpu load.



Pantxo Diribarne <pantxo>
Group Member
Tue 27 Oct 2020 08:02:20 PM UTC, comment #2: 

The OpenGL toolkits (fltk and qt) use single precision, that's why your plots look wrong and I think also why they behave unpredictably.

There are several bug reports about this on the tracker, see e.g.,
https://savannah.gnu.org/bugs/?func=detailitem&item_id=32980
In one of the bug reports there is a trick about pre-scaling the data.

Philip Nienhuis <philipnienhuis>
Group Member
Tue 27 Oct 2020 05:23:49 PM UTC, comment #1: 

The high CPU usage and long waiting time also happened with just 5 values:

S=[0.966087204808546,
0.966087204808546,
0.966087204808546,
0.966087217807083,
0.966087217807083]

T Knauss <tknauss>
Tue 27 Oct 2020 04:45:04 PM UTC, original submission:  

1) Create a Matrix from these values:
S = [0.966087133253521,
0.966087134195414,
0.966087134195414,
0.966087148503056,
0.966087148503056,
0.966087174908003,
0.966087174908004,
0.966087191418938,
0.966087191418939,
0.966087204808544,
0.966087204808545,
0.966087204808545,
0.966087204808545,
0.966087204808545,
0.966087204808545,
0.966087204808545,
0.966087204808545,
0.966087204808545,
0.966087204808545,
0.966087204808545,
0.966087204808545,
0.966087204808545,
0.966087204808545,
0.966087204808545,
0.966087204808545,
0.966087204808546,
0.966087204808546,
0.966087204808546,
0.966087204808546,
0.966087204808546,
0.966087204808546,
0.966087204808546,
0.966087204808546,
0.966087204808546,
0.966087217807083,
0.966087217807083]

2) Execute "plot(S)".

If the graphics toolkit is "qt" (seems to be the default, queried after the first test), the output is wrong. See attached screenshot.
If the graphics toolkit is "gnuplot" (chosen before the next test), the output seems to be correct, but it takes about 10 seconds with full load on 1 CPU core and about 30 more seconds with no CPU activity until the plot is displayed.
In "fltk", it seems to be correct and is shown instantly.
After switching back to "qt", the output seems to be correct, too, but it also takes time now.

Actually, it seems to become slower after every change of the graphics toolkit.

The behaviour can be reproduced by restarting Octave. The delay is not always reproducible.

T Knauss <tknauss>

 

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

Attach Files:
   
   
Comment:
   

Attached Files
file #50167:  bug59370_doc_gnuplot.patch added by mmuetzel (3KiB - application/octet-stream)
file #50141:  toto.png added by pantxo (7KiB - image/png)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by jwe (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 pantxo (Updated the item)
  • -email is unavailable- added by tknauss (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 group members can vote.

     

    Follow 15 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2020-11-05 mmuetzel StatusReady For Test Fixed
        Open/ClosedOpen Closed
    2020-10-30 rik5 StatusPatch Submitted Ready For Test
        Operating SystemMicrosoft Windows Any
    2020-10-30 mmuetzel Attached File- Added bug59370_doc_gnuplot.patch, #50167
        StatusConfirmed Patch Submitted
        Release5.2.0 6.0.92
    2020-10-30 mmuetzel Item GroupPerformance Documentation
        StatusNeed Info Confirmed
        SummaryPlotting produces wrong output or takes long time, depending on graphics toolkit Better document limitations of gnuplot graphics toolkit
    2020-10-29 rik5 StatusNone Need Info
    2020-10-27 pantxo Attached File- Added toto.png, #50141
        CategoryPlotting with OpenGL Plotting with gnuplot
        Item GroupIncorrect Result Performance
    2020-10-27 tknauss Attached File- Added octave@bug@-@plot(S)@with@qt.png, #50138

    Back to the top

    Powered by Savane 3.13-3230.
    Corresponding source code