Hi,
>
> The Qt widget and wxwidgets drivers keep their own, driver-specific,
> lists of all plotted elements. So when a plot window using one of
> those devices is resized the plot is replayed automatically using that
> list, rather than by calling plreplot or plRemakePlot. In order to
> have this support for the Cairo devices we either need to add
> something to cairo.c specifically or add support within PLplot's core
> for a non-device-specific plot replay buffer as I mentioned in my
> previous email.
That's not true for the wxWidgets driver. I use plRemakeplot. That's
also the reason why I don't completely understand this thread, since I
don't get from the discussion where exactly the problem is. The
wxWidgets driver plots into a off screen buffer, and remembers which
parts of the buffer were updated. Every now and then (at least when
the wxWidgets application takes over control) the plot on the screen
is updated. If the window is resized, some scaling parameters are
changed, the off screen plot buffer is resized if needed and
plRemakeplot is called - here I don't update the screen regularily, I
just wait for the outcome. There is some logic involved, so that all
functions know, that this is now a resize event, but this is actually
quite straightforward. If I use the wxWidgets driver to plot into an
extern canvas in an wxWidgets application, all is plotted in an off-
screen buffer. The application needs to take care (look in bindings/
wxWidgets) to copy that buffer to the screen, and what happens if the
widget is resized. I use the PLESC_RESIZE escape code to tell the
wxWidgets driver, that there is need to change scaling parameters and
buffer size. Maybe this is the straw you need?
>> How do you feel about the PLESC_INIT_FIT to rescale the canvas?
>
> I am not sure I understand your goal with this. Is it simply to allow
> the user to avoid setting the surface geometry themselves and have
> PLplot infer it from the clipping rectangle? I currently use
> plsetopt("geometry", "800x600") where 800x600 is the size of the Cairo
> surface to let PLplot know what size to use. I'm not sure if an extra
> PLESC_INIT_* path is needed as I could see it causing strange behavior
> and bugs which are difficult to track down if something other than
> PLplot is acting on the Cairo surface. If there is enough demand for
> this, though, then we can add it.
I also don't think that this is necessary, and I wouldn't add a esc
code, just for one driver, if there is a possibility to circumvent it.
Regards,
Werner
>
>
> Hez
>
> --
> Hezekiah M. Carty
> Graduate Research Assistant
> University of Maryland
> Department of Atmospheric and Oceanic Science
>
> ------------------------------------------------------------------------------
> Come build with us! The BlackBerry(R) Developer Conference in SF, CA
> is the only developer event you need to attend this year. Jumpstart
> your
> developing skills, take BlackBerry mobile applications to market and
> stay
> ahead of the curve. Join us from November 9 - 12, 2009. Register now!
> http://p.sf.net/sfu/devconference
> _______________________________________________
> Plplot-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/plplot-devel
--
Dr. Werner Smekal
Institut fuer Allgemeine Physik
Technische Universitaet Wien
Wiedner Hauptstr 8-10
A-1040 Wien
Austria
email: [email protected]
web: http://www.iap.tuwien.ac.at/~smekal
phone: +43-(0)1-58801-13463 (office), +43-(0)1-58801-13469 (laboratory)
fax: +43-(0)1-58801-13499
------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Plplot-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/plplot-devel
