From: Mark de W. <m.d...@da...> - 2009-09-24 11:23:57
Attachments:
extcairo.patch
plplot_test.tar.gz
|
Hi, I've been working on creating a plplot widget in gtkmm [1], this widget uses the extcairo driver. In order to get this widget working I've been making several modifications to the plplot sources. The first version of the widget did a full redraw for every modification and redraw. This was required since the only way to modify the size of the drawing area was the geometry command line parameter. This method resulted in two problems. The first was that it's too slow and has a lot of redraw flickering, the second that although the streams should be destroyed I run out of streams. (The attached example shows this issue.) So I went to look how to notify plplot about the changes in geometry. In the extcairo driver source for the PLESC_DEVINIT escape function there are some questions whether it should fit into the current context. plplot has access to the context and its clipping rectangle. Upon a full redraw the clipping rectangle is the entire context, when partially redrawn it's the dirty area. So it's only possible to get the size of the context upon a full redraw. I haven't been able to determine whether a redraw is partial or full from within the context, but it's possible to have this information on the caller side. So I added a extra escape function PLESC_DEVINIT_FIT which sets the size of the physical plot area to the clip rectangle. This also allows you to only draw a on a part of the context. As noted before [2] the offset is ignored, so it isn't possible yet to draw at an offset. (I might take up on Alan's offer to accept patches.) So in the current code PLESC_DEVINIT behaves as before and PLESC_DEVINIT_FIT adjusts the size of the physical plot area to the clip rectangle of the context. (I'm not entirely happy with that name and am open to better suggestions.) I use the PLESC_REDRAW escape function to redraw the widget when dirty. I'm not entirely sure whether this functionality should use PLESC_REDRAW or PLESC_EXPOSE. I also added the PLESC_RESIZE escape function, but that doesn't work as wanted yet. Attached a lightly tested proof-of-concept patch shows the new functionality and the attached sample program to show how it works and demonstrate some problems I still have. The sample program requires GTKMM and uses the cmake build system. The example also has some #if 0 parts to show some of the problems encountered; what goes wrong if a partial redraw would use PLESC_DEVINIT_FIT and current problem with PLESC_RESIZE and PLESC_DEVINIT_FIT. When using PLESC_DEVINIT_FIT or PLESC_RESIZE to resize the plot area plplot uses the new area, but the scaling doesn't work as wanted. I haven't found a solution yet, but I assume I need to call an/some extra function(s). I would be happy if somebody who has a deeper knowledge of the plplot core could help me to identify what's missing. The problem can be seen when the application is first shown, the widget labeled "Using clip extents, ori 0" doesn't look like the widget above it, after resizing the window and back to its original size it looks like the one above it. It also shows when the resizing uses PLESC_RESIZE. When using the geometry based widget the applications soon runs out of streams, when you resize the widgets. This seems like a bug, since the destructor of the object should free the stream. I might look into this issue later, for demonstration purposes I increased PL_NSTREAMS. I'm not familiar with the naming style of internal plplot functions I so just added the function with a fitting name (init_context), please let me know what would be the proper name for this function. Once PLESC_REDRAW/PLESC_EXPOSE and PLESC_RESIZE work properly it would be possible to let PLESC_DEVINIT always use the current clipping rectangle and remove the PLESC_DEVINIT_FIT escape function. But I'm not sure whether this is really wanted and/or how much existing code it would break. [1] http://gtkmm.org [2] http://www.mail-archive.com/plp...@li.../msg03634.html Regards, Mark de Wever |
From: Werner S. <sm...@ia...> - 2009-09-24 14:23:47
|
Hi, > This also allows you to only draw a on a part of the context. As noted > before [2] the offset is ignored, so it isn't possible yet to draw > at an > offset. (I might take up on Alan's offer to accept patches.) The offset is definitely not meant for this, mainly because in former times, there were no drivers which didn't provide it's on Window, except the memory driver. So it may be ok, to use the offset in the geometry option for windowless drivers as you mean it, but I wouldn't do so, since then one parameter has different meanings for different drivers, which is in my opinion not ok. The offset parameter is used to position the window on the screen. You need a window then obviously in the first place to apply the offset values. I actually don't fully understand, what your problem is - other drivers like the xwin driver, qt or wxwidgets driver use the PLESC_RESIZE escape code to be told, that the geometry changed. Depending on how the driver is implemented the scaling of the x and y axis are changed (proportional or not) and the plot is redrawn using the plot buffer. Look at these drivers to see how this is done. Regards, Werner -- Dr. Werner Smekal Institut fuer Allgemeine Physik Technische Universitaet Wien Wiedner Hauptstr 8-10 A-1040 Wien Austria DVR-Nr: 0005886 email: sm...@ia... 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 |
From: Mark de W. <m.d...@da...> - 2009-09-25 12:36:30
|
Hi Werner, Werner Smekal wrote: > Hi, > >> This also allows you to only draw a on a part of the context. As noted >> before [2] the offset is ignored, so it isn't possible yet to draw at an >> offset. (I might take up on Alan's offer to accept patches.) > > The offset is definitely not meant for this, mainly because in former > times, there were no drivers which didn't provide it's on Window, except > the memory driver. So it may be ok, to use the offset in the geometry > option for windowless drivers as you mean it, but I wouldn't do so, > since then one parameter has different meanings for different drivers, > which is in my opinion not ok. The offset parameter is used to position > the window on the screen. You need a window then obviously in the first > place to apply the offset values. From Alan's mail in that thread I understood that not using offset in the other drivers was seen as a minor omission. I see some use for the offset parameter for the extcairo driver; eg you could add a border to the widget and by setting a proper clip rectangle you can avoid plpot to draw over that part of the widget. But at the moment I've no use for the offset value. > I actually don't fully understand, what your problem is - other drivers > like the xwin driver, qt or wxwidgets driver use the PLESC_RESIZE escape > code to be told, that the geometry changed. Depending on how the driver > is implemented the scaling of the x and y axis are changed (proportional > or not) and the plot is redrawn using the plot buffer. Look at these > drivers to see how this is done. I already looked at those drivers to create my initial implementation, but my problem is that I seem to miss a minor part of the puzzle. This causes the resize not to work entirely as wanted. If you look at the sample program with the second #if 0 changed to #if 1 you can see the problem when you resize a widget which uses a clip rectangle. Regards, Mark de Wever |
From: Alan W. I. <ir...@be...> - 2009-09-26 19:01:31
|
On 2009-09-25 14:36+0200 Mark de Wever wrote: > From Alan's mail in that thread I understood that not using offset in > the other drivers was seen as a minor omission. I see some use for the > offset parameter for the extcairo driver; eg you could add a border to > the widget and by setting a proper clip rectangle you can avoid plpot to > draw over that part of the widget. But at the moment I've no use for the > offset value. Hi Mark: The first part of this is addressed to you, but the latter part makes general remarks about -geometry which should be of interest to all those who are writing interactive devices that ultimately (perhaps many levels deep) depend on X. The x,y offsets have nothing to do with the internals of plotting anything (such as clipping) or with the plotting widget itself (such as widget borders). Instead, those offsets are reserved exclusively (I agree with Werner about that) for specifying the position of the widget relative to the overall screen. In this way, the PLplot -geometry option (for those drivers who have implemented window offsets) should be interpreted exactly like the X -geometry option. See "man X" for details about -geometry. To see how this works in action, try a variety of negative and positive offset values as in -dev tk -geometry 100x100-100+100 You can do similar experiments for any X widget (such as xclock or xeyes). Note that -dev tk is a special case that interprets the -geometry option directly. In contrast, for -dev xwin, this is all handled via USPosition hints about what position the window should occupy. I discovered that -dev xwin does not respond properly to negative X or Y offsets (they are interpreted as 0). I have completed the first step in dealing with this (as of revision 10478 to plargs) to insure negative offset values are parsed correctly, and pls->xoffset and pls->yoffset properly updated to negative values. A side benefit of this update, is the new -geometry parsing logic using sscanf is much simpler than the old logic based on strtok. I have thrown every combination of bad geometry at that new logic that I can think of, and it seems to be well guarded against those type of issues. I have used gdb to show that, e.g., negative pls->xoffset now propagates to InitMain in drivers/xwin.c, but for some reason the XCreateWindow call still incorrectly interprets that negative USPosition hint as if the user asked for a 0 position. So some X expert here needs to figure that out if we ever want -dev xwin to respond properly to negative offsets. However, negative offsets are now parsed properly so that they should work (as in xeyes, xclock, and -dev tk) for other interactive devices such as xcairo and qtwidget _if_ those devices are updated to use the pls->[xy]offset values in a correct manner with regard to the underlying libraries (respectively from pango/cairo and Qt4) which ultimately depend on X. Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); PLplot scientific plotting software package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |
From: Mark de W. <m.d...@da...> - 2009-09-28 14:17:02
|
Hi Alan, Alan W. Irwin wrote: > On 2009-09-25 14:36+0200 Mark de Wever wrote: > >> From Alan's mail in that thread I understood that not using offset in >> the other drivers was seen as a minor omission. I see some use for the >> offset parameter for the extcairo driver; eg you could add a border to >> the widget and by setting a proper clip rectangle you can avoid plpot to >> draw over that part of the widget. But at the moment I've no use for the >> offset value. > > The x,y offsets have nothing to do with the internals of plotting anything > (such as clipping) or with the plotting widget itself (such as widget > borders). Instead, those offsets are reserved exclusively (I agree with > Werner about that) for specifying the position of the widget relative to > the > overall screen. In this way, the PLplot -geometry option (for those drivers > who have implemented window offsets) should be interpreted exactly like the > X -geometry option. See "man X" for details about -geometry. Then it seems I misunderstood your last mail about this subject. So the offsets of geometry are only useful for widgets the are shown in a Xwindow. That means I can ignore the offsets in my extcairo widget since it's not directly in a Xwindow. Regards, Mark de Wever |
From: Alan W. I. <ir...@be...> - 2009-09-28 15:21:54
|
On 2009-09-28 15:51+0200 Mark de Wever wrote: > Hi Alan, > > Alan W. Irwin wrote: >> On 2009-09-25 14:36+0200 Mark de Wever wrote: >> >>> From Alan's mail in that thread I understood that not using offset in >>> the other drivers was seen as a minor omission. I see some use for the >>> offset parameter for the extcairo driver; eg you could add a border to >>> the widget and by setting a proper clip rectangle you can avoid plpot to >>> draw over that part of the widget. But at the moment I've no use for the >>> offset value. >> >> The x,y offsets have nothing to do with the internals of plotting anything >> (such as clipping) or with the plotting widget itself (such as widget >> borders). Instead, those offsets are reserved exclusively (I agree with >> Werner about that) for specifying the position of the widget relative to >> the >> overall screen. In this way, the PLplot -geometry option (for those drivers >> who have implemented window offsets) should be interpreted exactly like the >> X -geometry option. See "man X" for details about -geometry. > > Then it seems I misunderstood your last mail about this subject. So the > offsets of geometry are only useful for widgets the are shown in a Xwindow. > That means I can ignore the offsets in my extcairo widget since it's not > directly in a Xwindow. I am pretty sure your conclusion is not correct. The offsets refer to the position of the widget on the X root window that corresponds to the physical device (monitor or LCD). So you can specify an offset relative to the constant root window for _every_ widget on Linux (since it ultimately uses X for display). I haven't looked deeper at it, but I assume both the Qt4 and cairographics library stacks provide access to this X capability for their respective X backends so it will be simply a matter of finding out how that is done and using the PLplot offsets appropriately. Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); PLplot scientific plotting software package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |
From: Alan W. I. <ir...@be...> - 2009-09-28 17:09:50
|
On 2009-09-28 08:21-0700 Alan W. Irwin wrote: > I am pretty sure your conclusion is not correct. The offsets refer to the > position of the widget on the X root window that corresponds to the physical > device (monitor or LCD). So you can specify an offset relative to the > constant root window for _every_ widget on Linux (since it ultimately uses X > for display). I haven't looked deeper at it, but I assume both the Qt4 and > cairographics library stacks provide access to this X capability for their > respective X backends so it will be simply a matter of finding out how > that is done and using the PLplot offsets appropriately. I just tried this idea with revision 10486. A quick look at the Qt4 documentation seemed to indicate move(ix, iy) was required for this and should be applied like resize. Therefore, I applied move right after the existing resize, and the result worked! Note, -dev qtwidget treats negative offsets as zero (just like -dev xwin), but positive offsets allow you to position the -dev qtwidget anywhere on the root window. And the implication of the Qt4 documentation is this method of positioning -dev qtwidget works for the Quartz (Apple) and Microsoft display backends for Qt4 as well. Note, there is no resize currently used in extqt, but I tried something similar to the (now) existing resize and move for the qtwidgets case, and there were no build errors or valgrind errors when I ran examples/c++/qt_example. However, that example was completely oblivious to PLplot -geometry options (size or offset) so I didn't commit that change. After all, I am only doing this by rote with no sound fundamental knowledge about what I should be doing here. Thus, I am leaving it to the Qt4/C++ experts here to get the -geometry option to work for examples/c++/qt_example and extqt in general. Also, I leave it to the cairo experts here to get offsets to work for xcairo and extcairo. I hope it will be just as straightforward for them as it was for me for the -dev qtwidget case. Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); PLplot scientific plotting software package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |
From: Hazen B. <hba...@ma...> - 2009-09-28 17:29:18
|
Alan W. Irwin wrote: > On 2009-09-28 08:21-0700 Alan W. Irwin wrote: > >> I am pretty sure your conclusion is not correct. The offsets refer to the >> position of the widget on the X root window that corresponds to the physical >> device (monitor or LCD). So you can specify an offset relative to the >> constant root window for _every_ widget on Linux (since it ultimately uses X >> for display). I haven't looked deeper at it, but I assume both the Qt4 and >> cairographics library stacks provide access to this X capability for their >> respective X backends so it will be simply a matter of finding out how >> that is done and using the PLplot offsets appropriately. > > I just tried this idea with revision 10486. A quick look at the Qt4 > documentation seemed to indicate move(ix, iy) was required for this and > should be applied like resize. Therefore, I applied move right after the > existing resize, and the result worked! Note, -dev qtwidget treats negative > offsets as zero (just like -dev xwin), but positive offsets allow you to > position the -dev qtwidget anywhere on the root window. And the implication > of the Qt4 documentation is this method of positioning -dev qtwidget works > for the Quartz (Apple) and Microsoft display backends for Qt4 as well. > > Note, there is no resize currently used in extqt, but I tried something > similar to the (now) existing resize and move for the qtwidgets case, and > there were no build errors or valgrind errors when I ran > examples/c++/qt_example. However, that example was completely oblivious to > PLplot -geometry options (size or offset) so I didn't commit that change. > After all, I am only doing this by rote with no sound fundamental knowledge > about what I should be doing here. Thus, I am leaving it to the Qt4/C++ > experts here to get the -geometry option to work for examples/c++/qt_example > and extqt in general. > > Also, I leave it to the cairo experts here to get offsets to work for xcairo > and extcairo. I hope it will be just as straightforward for them as it > was for me for the -dev qtwidget case. I'm still puzzled as to why this behavior is desired for extcairo & extqt. Both of these drivers use an externally supplied "context" to render the plot. To me it doesn't seem like a good idea for them to be able to move this context around on the screen and/or inside a window. I believe this should be the job of the program that supplied the context in the first place and that these drivers are doing the right thing by ignoring the -geometry option. If we want qt_example to respect the -geometry option then this should be done by the main qt window and not by the extqt widget attempting to move & resize its parent window. -Hazen |
From: Alan W. I. <ir...@be...> - 2009-09-28 18:33:34
|
On 2009-09-28 13:29-0400 Hazen Babcock wrote: >> Note, there is no resize currently used in extqt, but I tried something >> similar to the (now) existing resize and move for the qtwidgets case, and >> there were no build errors or valgrind errors when I ran >> examples/c++/qt_example. However, that example was completely oblivious to >> PLplot -geometry options (size or offset) so I didn't commit that change. >> After all, I am only doing this by rote with no sound fundamental knowledge >> about what I should be doing here. Thus, I am leaving it to the Qt4/C++ >> experts here to get the -geometry option to work for >> examples/c++/qt_example >> and extqt in general. >> >> Also, I leave it to the cairo experts here to get offsets to work for >> xcairo >> and extcairo. I hope it will be just as straightforward for them as it >> was for me for the -dev qtwidget case. > > I'm still puzzled as to why this behavior is desired for extcairo & > extqt. Both of these drivers use an externally supplied "context" to > render the plot. To me it doesn't seem like a good idea for them to be > able to move this context around on the screen and/or inside a window. I > believe this should be the job of the program that supplied the context > in the first place and that these drivers are doing the right thing by > ignoring the -geometry option. If we want qt_example to respect the > -geometry option then this should be done by the main qt window and not by > the extqt widget attempting to move & resize its parent window. I think that is a good argument which certainly simplifies our life. That just leaves xcairo to be made offset-aware from the above list. Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); PLplot scientific plotting software package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |
From: Mark de W. <m.d...@da...> - 2009-09-29 06:49:40
|
Alan W. Irwin wrote: > On 2009-09-28 13:29-0400 Hazen Babcock wrote: >>> Also, I leave it to the cairo experts here to get offsets to work for >>> xcairo >>> and extcairo. I hope it will be just as straightforward for them as it >>> was for me for the -dev qtwidget case. >> I'm still puzzled as to why this behavior is desired for extcairo & >> extqt. Both of these drivers use an externally supplied "context" to >> render the plot. To me it doesn't seem like a good idea for them to be >> able to move this context around on the screen and/or inside a window. I >> believe this should be the job of the program that supplied the context >> in the first place and that these drivers are doing the right thing by >> ignoring the -geometry option. If we want qt_example to respect the >> -geometry option then this should be done by the main qt window and not by >> the extqt widget attempting to move & resize its parent window. This is what I also thought when I wrote my previous mail. > I think that is a good argument which certainly simplifies our life. That > just leaves xcairo to be made offset-aware from the above list. Seems the misunderstanding is now completely resolved. Regards, Mark de Wever |
From: Hazen B. <hba...@ma...> - 2009-09-24 15:46:52
|
Werner Smekal wrote: > Hi, > >> This also allows you to only draw a on a part of the context. As noted >> before [2] the offset is ignored, so it isn't possible yet to draw >> at an >> offset. (I might take up on Alan's offer to accept patches.) > > The offset is definitely not meant for this, mainly because in former > times, there were no drivers which didn't provide it's on Window, > except the memory driver. I'm puzzled by this as well. If you want the plot at some offset in the window, then why not just offset the cairo context that you pass to PLplot? Since you created the cairo context you should have complete control of its location and size inside the window. -Hazen |
From: Mark de W. <m.d...@da...> - 2009-10-07 07:58:26
Attachments:
extcairo.patch
|
Mark de Wever wrote: > Hi, > > I've been working on creating a plplot widget in gtkmm [1], this widget > uses the extcairo driver. In order to get this widget working I've been > making several modifications to the plplot sources. I created a new patch in response to the discussion regarding the offset usage. I hope the other questions in my initial mail will be answered as well and some feedback about the patch in general. I haven't been able to get PLESC_RESIZE to work as wanted so disabled it for now. PLESC_INITFIT calls plbop() which causes the initial drawing to work as wanted. Since the offsets in the geometry aren't meant to be used as offset in the widget, the x1 and y1 of the clipping rectangle should both be 0.0 when used in PLESC_INITFIT. I added a warning if that pre-condition is not true. Regards, Mark de Wever |
From: Hezekiah M. C. <hez...@us...> - 2009-10-07 19:51:50
|
On Wed, Oct 7, 2009 at 2:58 AM, Mark de Wever <m.d...@da...> wrote: > Mark de Wever wrote: >> >> Hi, >> >> I've been working on creating a plplot widget in gtkmm [1], this widget >> uses the extcairo driver. In order to get this widget working I've been >> making several modifications to the plplot sources. > > I created a new patch in response to the discussion regarding the offset > usage. I hope the other questions in my initial mail will be answered as > well and some feedback about the patch in general. > > I haven't been able to get PLESC_RESIZE to work as wanted so disabled it for > now. > > PLESC_INITFIT calls plbop() which causes the initial drawing to work as > wanted. > Since the offsets in the geometry aren't meant to be used as offset in the > widget, the x1 and y1 of the clipping rectangle should both be 0.0 when used > in PLESC_INITFIT. I added a warning if that pre-condition is not true. 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. 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. I hope this helps. Hez -- Hezekiah M. Carty Graduate Research Assistant University of Maryland Department of Atmospheric and Oceanic Science |
From: Mark de W. <m.d...@da...> - 2009-10-13 13:10:58
|
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. > 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. How do you feel about the PLESC_INIT_FIT to rescale the canvas? Regards, Mark de Wever |
From: Hezekiah M. C. <hez...@us...> - 2009-10-15 04:20:46
|
On Tue, Oct 13, 2009 at 8:10 AM, Mark de Wever <m.d...@da...> 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 |
From: Werner S. <sm...@ia...> - 2009-10-15 06:14:06
|
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 > Plp...@li... > 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: sm...@ia... 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 |
From: Mark de W. <m.d...@da...> - 2009-10-15 12:57:52
|
Hi Hez, Hezekiah M. Carty wrote: > On Tue, Oct 13, 2009 at 8:10 AM, Mark de Wever <m.d...@da...> wrote: > 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. Thanks for the explanation. >> 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 use the geometry option for initial sizing, but when the widget gets resized I want to notify plplot that the size of the drawing area has changed. But maybe, since we don't want to implement the redraw, the code could also be executed in the normal PLESC_INIT routine and always use the size of the clipping rectangle. The other option would be to recreate the plstream object in my code for every resize, but I prefer to reuse the existing object. Regards, Mark de Wever |