octave-bug-tracker
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Dan Sebald
Subject: [Octave-bug-tracker] [bug #44916] Printing Qt-drawn figures produces faulty files
Date: Wed, 06 May 2015 06:35:51 +0000
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:18.0) Gecko/20100101 Firefox/18.0 SeaMonkey/2.15

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

Oh, I see.  Looking at the patch
https://savannah.gnu.org/support/download.php?file_id=33932 I now have a
little better understanding of the way gl2ps works.  There is a possibility
this is a thread timing issue.  Not 100% sure, but I'll explain.

Contrary to what I was thinking, the gl2ps code is not operating directly on
shared memory in threads.  There is some kind of feedback feature in OpenGL
that gl2ps is using to get a copy of the plot contents in a memory buffer. 
gl2ps then operates on that feedback buffer.

In gl2ps-renderer.cc, the general sequence of events is


  gl2psBeginPage();
  old_print_cmd = print_cmd;
  opengl_renderer::draw(go);
  glFinish();


It's inside gl2psBeginPage where the acquisition of the data occurs:


  gl2ps->feedback = (GLfloat*)gl2psMalloc(gl2ps->buffersize *
sizeof(GLfloat));
  glFeedbackBuffer(gl2ps->buffersize, GL_3D_COLOR, gl2ps->feedback);
  glRenderMode(GL_FEEDBACK);


There is a buffer created, that buffer is set up as the feedback buffer OpenGL
will use, then opengl_renderer::draw(go) fills in that memory--at least that
is how I understand it.  However, isn't it the case that opengl_renderer could
have some element of it that has main thread affinity, not the interpreter
thread?  If so, something in the opengl_renderer::draw chain of events could
end up queued across threads in Qt.  Then there will be a race condition.  The
::draw will be filling in the contents of gl2ps->feedback while the code in
the interpreter thread continues onward.  My guess is that most of the time
Martin sees random graphics because that feedback buffer is yet to be filled
when gl2ps operates on it.  However, it may be the case that once in a while
::draw finishes some of the plot before gl2ps operates on it, but it is never
the complete plot, i.e., the elements we've discussed as being dropped aren't
in the feedback buffer yet.

It seems to me that in the following code there might need to be a semaphore
wait as noted by []:


          if (ret == GL2PS_ERROR)
            {
              old_print_cmd.clear ();
              error ("gl2ps-renderer::draw: gl2psBeginPage returned
GL2PS_ERROR");
              return;
            }

          old_print_cmd = print_cmd;

          opengl_renderer::draw (go);

 [Need some kind of Mutex handshake right here to make ]
 [sure the above operation has completed if the draw is]
 [being done in the main thread.                       ]

          // Without glFinish () there may primitives be missing in the
          // gl2ps output.
          glFinish ();


Just my thoughts.  There is a possibility this could be the source of the
strange graphics I see when printing in Qt.  That is, Qt redraw/rendering
while in GL_FEEDBACK mode maybe, perhaps?  Maybe that has a strange effect. 
Don't know.

    _______________________________________________________

Reply to this item at:

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

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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]