[Octave-bug-tracker] [bug #51631] make check fails at __opengl_info__

[Rik]

Follow-up Comment #18, bug #51631 (project octave):

Ick!  There are definitely weird timing patterns.  

The graphic properties are maintained in graphics.cc and graphics-props.cc and
they exist independently of the backend.  This allows Octave to support a
toolkit like gnuplot, but it also means there can be consistency issues.  In
this case, the backend toolkit itself is calculating values, like
__gl_version__, and then assigning to the property database.  If the Octave
interpreter queries the property database before the toolkit has updated the
values then it gets bad results.

I added some debug statements to Fdrawnow to see when the refresh() call was
actually forcing the graphics system to redraw things.  I also added a debug
statement in graphics-props.cc to check when __gl_version__ was being queried
with a get statement.

The m-file code was


octave:12> hf = figure; hax = axes; pause (2); get (hf, "__gl_version__")
drawnow_executing: 0
getting __gl_version
ans = 
octave:13> draw_figure


As you can see, the get() statement is executing before the call to
draw_figure and a large pause makes no difference at all.  It seems that pause
halt the entire execution thread, including the FLTK toolkit.  A refresh()
statement by itself is not enough. 


octave:21>     hf = figure; hax = axes; refresh (hf); get (hf,
"__gl_version__")
drawnow_executing: 0
getting __gl_version
ans = 
octave:22> draw_figure


But reset with a pause is


octave:23>     hf = figure; hax = axes; pause (.1); refresh (hf); get (hf,
"__gl_version__")
drawnow_executing: 0
drawnow_executing: 0
draw_figure
getting __gl_version
ans = 3.0 Mesa 17.0.7





    _______________________________________________________

Reply to this item at:

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

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