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

[Dan Sebald]

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

Thanks for trying the green background.  I think it is good to just confirm
what is happening before searching for bigger problems.  Well, definitely
elements of the plot are being dropped.  That's confirmed.  I loaded one of
the SVG plots into inkscape and ungrouped the plot.  Individual plot elements
are used, not some big bitmap.

Threading is always a concern, but in this case I don't know if that is a
problem because the gl2ps/OSMesa code may be running in the same thread as
Octave core.  (Qt graphics certainly is not in the same thread.)  I've looked
a bit and it seems __osmesa_print__() is being run from the worker Octave
interpreter thread.

What complicates this is that gl2ps does more than just translate the OpenGL
commands to some output format, i.e., a simple driver.  Here is what the doc
indicates:

"
The main difference between GL2PS and other similar libraries (see section 7)
is the use of sorting algorithms capable of handling intersecting and
stretched polygons, as well as non manifold objects. GL2PS provides advanced
smooth shading and text rendering, culling of invisible primitives, mixed
vector/bitmap output, and much more... 
"

Culling of invisible primitives makes me think that gl2ps could be the code
that is dropping the axis line and one of the triangles from the background. 
Of course, it is mistakenly doing so, if that is the case.  What configuration
on Octave's side would make gl2ps think some primitive is hidden when it
isn't?

Let's go back to the thread hypothesis.  The way that the random bug could
occur would be a thread clash, i.e., two threads operating on the same memory
simultaneously.  It doesn't seem likely (or should I say necessary?), yet on
the other hand, something comes to mind which is that I've often seen the Qt
terminal go into this strange state at the moment of printing in which random
splotches of color appear, and when printing is complete the drawing comes
back to normal.  Is it possible that a redraw is occurring in Qt at the same
moment as gl2ps is working?  If so, should this even be a problem if the
memory accessed is only being read and not modified?  (If it were a bus issue,
sure, but I think all those sorts of bus clashes are worked out at the
firmware level.)

There's lots going on here.  Hard to pin down.


    _______________________________________________________

Reply to this item at:

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

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