Re: [RFC] octave-to-backend notification of property change

[Michael Goffioul]

On Fri, Jul 4, 2008 at 3:06 PM, David Bateman
<address@hidden> wrote:
> Does the drawnow in most cases only happen when you come back to the
> prompt. In that case option 2 would be completely unresponsive unless
> the user included the drawnows in their program.

The competition documentation states that the graphics event queue is
automatically flushed when octave prompt returns or when the following
functions are called: drawnow, input, pause, getframe, ginput, waitfor
(and maybe a few others I don't remember). So basically, the queue is
flushed just before the user can potentially interact again.

So indeed, option 2 is a matter of responsiveness. OTOH, do you see
a use-case when such unresponsiveness is not acceptable? Axes
rendering for instance does not occur until the next drawnow anyway.

> Also your example
>
> figure;
> for k=1:500, set(gcf, 'position', [k 50 500 500]), end
>
> running in th ehg head with the fltk backend resulted in the figure in
> the initial state in the upper right corner of the screen and then
> instantly in a final state without passing through any intermediate
> states, which seems to confirm that the drawnow is only at the return to
> the prompt.

The octave-to-backend notification I experimented (option 1) is not
in hg head, so the observed behavior is normal. There is also a
specific behavior in FLTK backend in the sense that the GUI event
loop is run synchronously with octave thread, within input_event_hook
handler. So the GUI is completely frozen (no event dispatching) when
octave is not waiting for user input.

Michael.