Re: Octave/backend synchronization

[Michael Goffioul]

This time, with the attachment...

Michael.


On Jan 23, 2008 10:55 AM, Michael Goffioul <address@hidden> wrote:
> Hi,
>
> I'd like to propose the following patch. The goal is to implement a
> basic symchronization
> scheme between octave and a graphics backend. The idea is not to implement a
> fully-featured multithread support, but at least to provide a way to
> perform rendering
> in a separate thread, without race condition problems. This is
> motivated by the fact
> that in some graphics system (like Java), the GUI event-loop run
> automatically in
> a separate thread; hence the redraw requests will occur in this separate 
> thread.
> The proposed scheme allows to "lock" completely access to the graphics system
> and should be enough for rendering purposes (and maybe special actions like
> 3D rotation).
>
> Note that it is not my intention to run callbacks (like when pushing a
> button) in
> a separate thread; these should be run synchronously with octave.
>
> The proposed code contains only the Windows implementation. I leave the UNIX
> implementation for people able to compile and run it. I tried to keep
> the implementation
> as lightweight as possible.
>
> Michael.
>
> src/ChangeLog
>
> 2008-01-23  Michael Goffioul <address@hidden>
>
>    * graphics.h.in (class gh_manager): New static methods lock/unlock
>    and instance methods do_lock/do_unlock.
>    * graphics.cc (class gh_manager): Likewise (Windows implementation).
>    (Fishandle, Fset, Fget, F__get__, F__go_figure__, F__go_axes__,
>    F__go_line__, F__go_text__, F__go_image__, F__go_surface__,
>    F__go_patch__, F__go_delete__, F__go_axes_init__,
>    F__go_handles__, F__go_figure_handles__, Fdrawnow,
>    get_property_from_handle, set_property_in_handle): Use locking
>    mechanism.
>

graphics-sync.diff
Description: Text document