On Tue, Oct 13, 2009 at 8:10 AM, Mark de Wever <[email protected]> wrote:
> Hi Hez,
>>
>> Mark,
>>
>> Based on my experience using extcairo, I think that most of the items
>> addressed by your patch would be better to handle on the client/GUI
>> side rather than in PLplot itself.
>>
>> Using the current extcairo device, providing an offscreen Cairo
>> surface to render to is much faster than providing the GUI window
>> widget directly to PLplot. This avoids needing to deal with PLplot at
>> all when an expose event occurs as the offscreen surface can be
>> painted on to the widget surface.
>
> Thanks for this suggestion, I looked into it and did some testing. The
> offscreen surface doesn't seem to be faster for me (I have a lot of
> updates), but the code for the widget is simpler.
I have worked around this somewhat by only updating the widget from
the off-screen surface a few times each second. This won't work for
applications which need more frequent updates. One way to possibly
speed this up it to only update the modified/dirty portion of the plot
surface.
>> For the resize case, forcing PLplot to do a replot with plreplot or
>> plRemakePlot will unfortunately just replay the same plot graphics,
>> with the same physical (pixel) dimensions. If this is acceptable for
>> your application then you can: (1) keep the widget at a fixed size,
>> even if the window is resized; (2) stretch the offscreen canvas to fit
>> the new widget dimenions; or (3) show the plot with the same physical
>> size centered or otherwise positioned within the widget.
>>
>> If that is not acceptable, then either a plot buffer needs to be
>> maintained by the user application or a change could be made to the
>> PLplot stream buffer to accommodate this. A function could be added to
>> PLplot which replays a plot stream's buffer in a manner which is
>> independent of the output canvas size. Doing this correctly would
>> require (as has been mentioned) that either the PLplot Cairo driver
>> keep its own record of plotted elements or such a record is kept as
>> part of the PLplot stream. I think that making this a
>> non-driver-specific part of PLplot would be the ideal solution as all
>> drivers could benefit from the implementation. I haven't looked in to
>> this in much detail yet so there may be cross-device difficulties
>> implementing a generic (re)plot stream.
>
>>
>> All that said, I still think that the actual replay of the plot buffer
>> should be handled by the client application rather than PLplot. A
>> "plreplay" function could ease this and allow the programmer to decide
>> how they want to handle a resized canvas.
>
> For my application I need the widget to be able to scale. Since the Xwin
> driver is able to do that, I thought it would be possible. But I found out
> it isn't and for now I just redraw the plot in the newly sized widget.
> It would be nice if it was possible to do it with a plreplay command. I also
> wonder how the Qt widget and the wxwidget handle this.
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.
> 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.
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
