[Octave-bug-tracker] [bug #53513] graphics.cc-tst FAIL

[Rik]

Follow-up Comment #3, bug #53513 (project octave):

A little debugging shows that I do not have this problem, even in the GUI, if
I am using the FLTK toolkit.  This is something unique to the Qt toolkit.  I
extracted the one failing test in to a new file tst_ui.m which is attached. 
You can use 'test tst_ui' to run just this one problem test.

At least part of the issue is related to the new QTOFFSCREEN rendering that we
are using for invisible figures.  If I change the first line of the file to
make the figure visible then 75% of the time the test passes.  That still
sucks, but it is an indication that whatever it is gets far worse when the
figure is hidden.  Just guessing, but when the figure is hidden graphics
operations take place much quicker which might be showing what race condition
exists.

Finally, it only takes one very small delay, I used a millisecond, after the
call to delete to get this to work.


%!test
%! hf = figure ("visible", "off");
%! #hf = figure ("visible", "on");
%! hax = axes ("parent", hf);
%! unwind_protect
%!   hctx1 = uicontextmenu ("parent", hf);
%!   hctx2 = uicontextmenu ("parent", hf);
%!   set (hf, "uicontextmenu", hctx2);
%!   set (hax, "uicontextmenu", hctx2);
%!   assert (get (hf, "uicontextmenu"), hctx2);
%!   assert (get (hax, "uicontextmenu"), hctx2);
%!   assert (get (hf, "children"), [hctx2; hctx1; hax]);
%!   delete (hctx2);
%!   pause (0.001);   # <-- Required for Qt toolkit
%!   assert (get (hf, "uicontextmenu"), []);
%!   assert (get (hax, "uicontextmenu"), []);
%!   assert (get (hf, "children"), [hctx1; hax]);
%!   set (hf, "uicontextmenu", hctx1);
%!   assert (get (hf, "uicontextmenu"), hctx1);
%!   set (hf, "uicontextmenu", []);
%!   assert (get (hf, "uicontextmenu"), []);
%!   assert (get (hf, "children"), [hctx1; hax]);
%! unwind_protect_cleanup
%!   close (hf);
%! end_unwind_protect;


The assert which fires is saying that the uicontextmenu entry for the figure
is not empty, as it should be after the delete, but still contains a 1x1 entry
(presumably this is hctx2).

This leads me to believe that there is something amiss with the way we
implement delete.  The handle that we are deleting, hctx2, is destroyed
immediately.  But this will cause other callbacks to fire which then remove
hctx2 from the "children" property of the parent of hctx2.  I think control
must be returning to the command line before those updates have had a chance
to complete.

How is the event queue flushed?  Is only one cycle done each time Octave
returns to the command prompt?  Or is the event queue fully emptied before
returning to the command prompt.  The second choice seems better because
operations, like delete, could spawn new events which need to be processed.


(file #43733)
    _______________________________________________________

Additional Item Attachment:

File name: tst_ui.m                       Size:0 KB


    _______________________________________________________

Reply to this item at:

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

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