[Top][All Lists]

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

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

From: Rik
Subject: [Octave-bug-tracker] [bug #51631] make check fails at __opengl_info__
Date: Tue, 1 Aug 2017 21:01:15 -0400 (EDT)
User-agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:54.0) Gecko/20100101 Firefox/54.0

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,
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,
drawnow_executing: 0
drawnow_executing: 0
getting __gl_version
ans = 3.0 Mesa 17.0.7


Reply to this item at:


  Message sent via/by Savannah

reply via email to

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