Mon 31 Oct 2016 07:35:39 PM UTC, comment #11:
Octave doesn't have control over the wording of the message--it is produced by GL2PS. Instead, I added an additional message from Octave that informs the user what is happening. I checked that change in here (http://hg.savannah.gnu.org/hgweb/octave/rev/b5407b1ab11a).
When I run the example in this report I now get these messages:
The messages are repeated twice because when producing Latex output the scene is rendered twice. This seems like a point that could be optimized so I filed a bug report about that at bug #49492.
|
Mon 31 Oct 2016 07:30:11 PM UTC, comment #10:
The status is closed. so this is probably useless, but please realize that the current message is exactly the same as was sent before this problem was resolved (bug 46417). Since there has been no announcement that that bug was resolved, a user has no way of knowing where this is a problem or not. Unlike developers, the lay user is trying to get something done that is quite different, eg getting figures ready for publication. While it could be that a message like "don't worry Im still trying" might help the impatient, the current message stating that there is a buffer overflow w/o indication that something is done about it is unhelpful at best.
|
Mon 31 Oct 2016 05:58:41 PM UTC, comment #9:
Maybe simply change the message:
"GL2PS info: OpenGL feedback buffer overflow"
into
"GL2PS info: OpenGL feedback buffer overflow, buffer size adapted"
-or-
"GL2PS info: OpenGL feedback buffer overflow, re-trying with larger buffer"
-or maybe even simply-
"GL2PS info: re-trying with larger buffer"
?
I second Andreas' comment that the message can be useful info, but I also seond Clinton's comment that unwary users should receive info that isn't needlessly worrying for them.
I find that many users simply do not know/appreciate that the word "info" means that what follows refers to a harmless condition, while for developers that seems obvious.
|
Mon 31 Oct 2016 08:06:27 AM UTC, comment #8:
Octave doesn't "built the displayed image" it uses OpenGL which the face culling, tesselation and so on. gl2ps uses the glFeedbackBuffer to capture the commands and convert them to postscript. It's like listening on a serial port: You don't know how much data will be sent until it's finished because there is no header.
The info message you see is output by the gl2ps. We can just disable all output or let it be chatty. For me the message is usefull to show that there is still progress and the buffer keeps growing.
|
Mon 31 Oct 2016 03:00:14 AM UTC, comment #7:
One would think that in such a process, octave would first evaluate the required buffer size. It has already built the displayed image so must have the required information. This would avoid time consuming and inefficient iterations.
From the user's perspective the question is if the message is irrelevant to her process, why bombard her with information she can do nothing about except wonder if the file produced is correct or not?
|
Mon 31 Oct 2016 02:57:51 AM UTC, comment #6:
Dmitri has diagnosed this correctly. We can't know initially what buffer size will work for all images, so we start with a given size and let gl2ps try and render it. If gl2ps tells Octave that the buffer was too small, then we double the buffer and try again. We keep doing this until the image is finally rendered successfully. The messages that are sent to stderr include the word "info" to indicate that this is not an error.
|
Mon 31 Oct 2016 01:32:10 AM UTC, comment #5:
Octave tries to print with some pre-determined buffer size.
If it is too small gl2ps returns error and octave double the buffer size and tries again and so on.
You can see the code in gl2ps-print.cc file starting at about line 210.
Dmitri.
--
|
Mon 31 Oct 2016 01:18:03 AM UTC, comment #4:
Not sure I understand the latest comment. The output file is either correct or not. If it is correct why would the user be informed repeatedly that there is a buffer overflow?
|
Mon 31 Oct 2016 12:59:10 AM UTC, comment #3:
This is not an error, just an information message.
You do get a correct output file, don't you?
Dmitri.
--
|
Mon 31 Oct 2016 12:02:30 AM UTC, comment #2:
Same problem with 4.2.0-rc2, only for a slightly larger file size:
Isnt this a gl2ps issue rather than an octave issue??
|
Sun 30 Oct 2016 09:34:24 PM UTC, comment #1:
Version 4.0.3 is just about to be deprecated. Please try with the latest 4.2.0-rc2 release candidate (http://alpha.gnu.org/gnu/octave/octave-4.2.0-rc2.tar.xz). This works for me.
|
Sun 30 Oct 2016 07:15:59 PM UTC, original submission:
|