[Octave-bug-tracker] [bug #44916] Printing Qt-drawn figures produces faulty files

[Dan Sebald]

Follow-up Comment #35, bug #44916 (project octave):

OK.  Can't rule out multiple issues happening that might be confusing
matters.

To get some insight, it might be useful to compare the contents of the
feedback buffer between a properly working system (wouldn't have to be any
particular kind, I think).  That is, after calling


         opengl_renderer::draw (go);


place a short hunk of code that sends the contents of

gl2ps->feedback

to a binary file.  One can then do a binary comparison between feedback data
for a working system and non-working system--sort of pick apart what may be
happening.  If the binary data compares exactly, then it could be that gl2ps
has a bug or is using an incompatible header definition for the API.  If the
binary data doesn't compare exactly, then one could open the files in a binary
editor and search for the hex equivalents to the tokens that OpenGL is using. 
Does that sound like more work than the help it would yield?

[
This is an aside, but I think that this feedback mode really could be the
source of the temporary flash of colors I see.  In the gl2ps code I only see
the one instance where the render mode is changed back to GL_RENDER.  I.e.,


static GLint gl2psPrintPrimitives(void)
{
  GL2PSbsptree *root;
  GL2PSxyz eye = {0.0F, 0.0F, 100.0F * GL2PS_ZSCALE};
  GLint used;

  used = glRenderMode(GL_RENDER);

  if(used < 0){
    gl2psMsg(GL2PS_INFO, "OpenGL feedback buffer overflow");
    return GL2PS_OVERFLOW;
  }

  if(used > 0)
    gl2psParseFeedbackBuffer(used);


What happens if during the time that the Qt figure window attempts to redraw
the figure?  At least the feedback buffer is cleared from memory after the
render mode is turned back to GL_RENDER.  Otherwise doing an asynchronous
replot in a different thread would be a problem...  BTW, it might be useful to
print out the value of "used" in the above gl2ps code.
]

The gl2ps documentation could be a tad clearer on what it is doing.  I mean,
now I understand more having seen the innards.  However, the statement about
gl2ps culling primitives is not an accurate one.  The culling actually happens
*prior* to gl2ps and gl2ps has culling simply as a matter of consequence. 
Here's documentation on the glFeedbackBuffer routine:

https://msdn.microsoft.com/en-us/library/windows/desktop/dd373532(v=vs.85).aspx

http://www.glprogramming.com/red/chapter13.html

Note that

"
Each block begins with a code indicating the primitive type, followed by
values that describe the primitive's vertices and associated data. The
glFeedbackBuffer function also writes entries for bitmaps and pixel
rectangles. Feedback occurs after polygon culling and glPolygonMode
interpretation of polygons has taken place, so polygons that are culled are
not returned in the feedback buffer. It can also occur after polygons with
more than three edges are broken up into triangles, if the OpenGL
implementation renders polygons by performing this decomposition.
"

All right that pretty much confirms that the primitives are culled before
reaching gl2ps.

FWIW, if intricate debugging is required, it's possible to put some marker
tokens in the feedback buffer data using glPassThrough:

"
You can insert a marker into the feedback buffer with glPassThrough.
"

OK, so why is OpenGL culling lines when sent to the feedback buffer as opposed
to one of the video drivers?  Is there something configuring the image size
that is supposed to be used by OpenGL for the feedback buffer?  Some other
obscure setting?


    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?44916>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/