RE: XForms: Problem displaying images

Michael Glickman (michaelg@linx.com.au)
Wed, 15 Sep 1999 16:03:29 +1000

# To subscribers of the xforms list from Michael Glickman <michaelg@linx.com.au> :

As indicated the section of the code I included,
the canvas is moved programmatically (fl_set_object_position)
and I also
execute a pic->display and XFlush(fl_display) after the move.

Sorry, I realised that straight after the mail was sent

> have also tried moving the canvas by traping a mouse event with the
> same results.
>
> Mouse event may be relevant in your particular situation,
> however I referred to a proprietary canvas handler (specified by
> fl_set_canvas_handler, as far as I remember). Since canvas
> is a low-level object, and only slightly automated, this handler
> is desirable for trapping at least Exposure events (i.e. X-event
> raised whenever a window needs to be re-painted). This is
> where pic->display seems natural to place (XFlush is not
> needed in this context). If you put re-painting code elsewhere,
> it may happen that XForms will also use its default routine
> for handling exposure events. that conflicts with what
> you are going to get.
>
> The only way it works is to free the pic and reload it into
> the canvas. But that is very inconvenient.
> I agree. As I guess, you are going to include a kind of
> animation where the time factor is crucial. Reloading an
> image might take ages. BTW this is another argument for
> XPM, given the ability to use XCopyArea that sends an
> image from pixmap directly to the window.
>
> All the best in your artwork :-)
> Michael
>
_________________________________________________
To unsubscribe, send the message "unsubscribe" to
xforms-request@bob.usuhs.mil or see
http://bob.usuhs.mil/mailserv/xforms.html
XForms Home Page: http://bragg.phys.uwm.edu/xforms
List Archive: http://bob.usuhs.mil/mailserv/list-archives/