On Sun, Aug 23, 2009 at 5:52 AM, Werner Smekal<sme...@iap.tuwien.ac.at> wrote: > On Aug 22, 2009, at 11:04 PM, Hezekiah M. Carty wrote: >> For anyone interested, I have attached a patch for the Cairo plot >> driver which speeds up plotting to the xcairo device considerably, >> with the caveat that the plot contents will not appear in the plot >> window until a flush occurs by one of: >> >> - A call to plflush >> - The end of the page is reached (e.g., pleop, plenv to start a new >> page, plend/plend1 to end the plot stream) > > I was just thinking about the same change to the wxWidget driver ;) >> >> This patch puts the behavior of the xcairo device somewhere between >> the xwin driver which updates the plot display as it is made and the >> qtwidget device which does not display the plot until the end of a >> page. >> >> The rendering speedup is attained by rendering the plot to an >> off-screen surface and only updating the visible window when >> requested. With this patch applied, the PLplot examples render as >> fast or faster on my system (64bit Linux, Cairo 1.8.6) with the xcairo >> device as they do with the xwin device, without any flickering and >> with all anti-aliasing enabled. > > Really faster then xwin? That would be quite unexpected. I would only > believe that if cairo takes advantage of the graphics hardware.
I think it comes down to the continuous xwin on-screen updates, which there are no on-screen updates until the page is complete for xcairo with this patch. Cairo's off-screen rendering is quite quick. On my system, according to the rather unscientific test of holding enter after typing "time ./x11c -dev xwin" and "time ./x11c -dev xcairo", I get ~1.8 seconds for xwin and ~1.2 seconds for xcairo. Conversely, for example 16, xwin takes ~1.1-1.2 seconds while xcairo takes ~1.2-1.4 seconds. >> The compiled PLplot examples illustrate the speedup (particularly >> examples 11, 16 and 20) and flicker-free rendering (example 17) quite >> nicely. The shortcoming of not seeing the plot updates until a flush >> becomes most noticeable when using the xcairo driver interactively, >> say from an interactive Octave, OCaml or Python session. This lack of >> interactive updates could be worked around with threading similar to >> the pthread use in the xwin driver. The xwin threading code is quite >> lengthy and complicated though, so this would likely be a fairly >> significant task. > > In the moment for the wxWidgets driver I update the screen every 100 > commands or so, which makes the driver slow - I actually believe that the > xwin driver does something similar (at least I got the idea from there). We > could introduce a command line option to set this parameter. If not set the > driver waits for plfush() or pleop(), if set it updates every x plot > commands. Otherwise I don't think it's so bad, that you need plflush(). It's > an extra command, but on the other side it gives you full control as a user. > I also intend introducing threading in the wxWidgets driver, but this is > maybe simpler, since wxWidgets provides such functionality. A command line option to adjust the number of plot updates before a display update sounds like a good idea. "0" could mean only update on a flush/eop, "1" would be update after each plotting event (the current pre-patch behavior), and so on. I agree that "0" is a sensible default. I'm a little concerned that using a value like 100 updates for xcairo would lead to strange results during interactive use unless it is combined with some sort of timing-based threaded updates. Otherwise an update might trigger in the middle of, for example, a shade or image plot, leaving the user looking at what appears to be a broken plot command but is really just not fully updated on screen. >> I have been using this patch locally for about 6 months. I find it >> makes the xcairo device much more useful for me. The speedup provided >> by the off-screen rendering allows me to use the xcairo and its >> improved rendering quality where I would have formerly used xwin due >> to its impressive speed. >> >> All that said, I would like to ask for comments from others on this >> patch before applying it to PLplot. I had asked a few other >> developers for comments on a similar patch several months ago, with >> the main concerns voiced at the time centering around the lack of >> visible updates as a plot is made unless plflush is called or the plot >> page ends. This is a significant visible change to how the xcairo >> device works. I intended to bring the discussion of this on-list at >> that time, but clearly this was delayed by a few months! > > I think it's okay, but maybe a command line option for setting the update > rate would be great. We set it to a certain number, so that the average user > will not see to much difference if the plot is updated every 100 commands. > But it'll be faster which is always a good thing. This would be a fairly invasive code change in the Cairo driver, as each plotting function would have to call the check-and-possibly-update-the-screen function. I can look in to what it would take to do this versus adding basic threading support for screen updates to the xcairo device. Thank you for the comments. Hez -- Hezekiah M. Carty Graduate Research Assistant University of Maryland Department of Atmospheric and Oceanic Science ------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
