From: Alan W. I. <ir...@be...> - 2009-07-29 18:34:54
|
I have just (revision 10188) enabled alpha channel/transparency for our background colour for the cairo and svg device drivers. These drivers thus join the gd device driver in handling this correctly, and I hope later this week, Alban will be able to enable the same functionality for the qt devices (along with his planned changes to enable rgb background colour for the qt devices.) For now you can see what semi-transparent backgrounds look like by locally changing the second line of cmap0_black_on_white.pal from #ffffff 1.0 to, e.g., #ff0000 0.3 which gives a red mostly transparent background for the gd, cairo, and svg devices (and an opaque red background for our devices which are not transparency aware). I would also like to specify the transparency of the background conveniently using the -bg command-line option. I was thinking along the lines of -bg ff0000_0.3 to specify the same semitransparent background that I gave as an example above. The implementation would simply check the length of the option string and if greater than 6, parse the first 6 as hex, check for the underscore, and parse the remainder as a floating point value. Please comment _soon_ if you forsee any trouble with that implementation idea. Of course, our current semitransparent background results look rather dull because linux applications still are not as transparency aware as they should be, and therefore, they currently tend to impose opaque backgrounds of their own upon which the PLplot background is superimposed. To sort out which background is which, you can sometimes specify a background colour for the application. For example, the ImageMagick "display" application has the -background option to specify an opaque colour for their background, and I was able to use that "display" option to prove that _our_ background transparency was working correctly for the gd, cairo, and svg devices. (Of course, it would be nice if the "display" background could be semi-transparent as well so I hope some ImageMagick developer is working on that.) In the future, as Linux and other OS's become completely transparency aware, I can forsee our semi-transparent background capability allowing for some really cool effects such as superimposing our plots on top of other images or just on top of the general desktop behind where one of our plots is displayed. Anyhow, that was the motivation for the latest commit and will also be the motivation for the planned change to the -bg command-line option. 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: Werner S. <sm...@ia...> - 2009-07-29 19:21:29
|
Hi Alan, > I would also like to specify the transparency of the background > conveniently > using the -bg command-line option. I was thinking along the lines of > > -bg ff0000_0.3 > > to specify the same semitransparent background that I gave as an > example > above. The implementation would simply check the length of the > option string > and if greater than 6, parse the first 6 as hex, check for the > underscore, > and parse the remainder as a floating point value. Please comment > _soon_ if > you forsee any trouble with that implementation idea. I don't see any trouble, but what about -bg ff0000 for opaque and -bg ff00003f for transparent background. This would be much easier to check (must be 6 or 8 chars) and transparency has most of the times 255 values anyway AFAIK (depending on the implementation, e.g. png). But you solution would be also ok. 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: Alan W. I. <ir...@be...> - 2009-07-29 20:25:37
|
On 2009-07-29 21:20+0200 Werner Smekal wrote: > Hi Alan, > >> I would also like to specify the transparency of the background >> conveniently >> using the -bg command-line option. I was thinking along the lines of >> >> -bg ff0000_0.3 >> >> to specify the same semitransparent background that I gave as an example >> above. The implementation would simply check the length of the option >> string >> and if greater than 6, parse the first 6 as hex, check for the underscore, >> and parse the remainder as a floating point value. Please comment _soon_ >> if >> you forsee any trouble with that implementation idea. > > I don't see any trouble, but what about > > -bg ff0000 > > for opaque and > > -bg ff00003f > > for transparent background. This would be much easier to check (must be 6 or > 8 chars) and transparency has most of the times 255 values anyway AFAIK > (depending on the implementation, e.g. png). > > But you solution would be also ok. Thanks for your bringing up the possibility of an 8-bit representation for the command-line value of alpha. That would certainly work, but I prefer the command-line values be consistent with the cmap0 related PLplot commands which use 8-bit representations of rgb, and a floating representation of the alpha value. 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-07-29 23:29:34
|
On 2009-07-29 13:24-0700 Alan W. Irwin wrote: > Thanks for your bringing up the possibility of an 8-bit representation for > the command-line value of alpha. That would certainly work, but I prefer > the command-line values be consistent with the cmap0 related PLplot commands > which use 8-bit representations of rgb, and a floating representation of the > alpha value. Now implemented (revision 10189). So to check device drivers for proper handling of semitransparent background colours, you don't have to edit cmap0 palette files any more. Instead, just use the -bg option with alpha specified, e.g., -bg 0000FF_0.1 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: Alban R. <a.r...@im...> - 2009-07-30 13:18:04
Attachments:
qt_patch.gz
|
Dear Alan and PLplot community, Please find attached an update for the Qt driver, allowing changes to the background colors (supporting transparency), based on svn revision 10819. I should submit quite soon another patch for the driver, making the code a bit cleaner (not changing the general architecture of the driver though) and making the driver faster. Alban Alan W. Irwin wrote: > I have just (revision 10188) enabled alpha channel/transparency for our > background colour for the cairo and svg device drivers. These drivers thus > join the gd device driver in handling this correctly, and I hope later this > week, Alban will be able to enable the same functionality for the qt devices > (along with his planned changes to enable rgb background colour for the qt > devices.) > > For now you can see what semi-transparent backgrounds look like > by locally changing the second line of cmap0_black_on_white.pal from > > #ffffff 1.0 > > to, e.g., > > #ff0000 0.3 > > which gives a red mostly transparent background for the gd, cairo, and svg > devices (and an opaque red background for our devices which are not > transparency aware). > > I would also like to specify the transparency of the background conveniently > using the -bg command-line option. I was thinking along the lines of > > -bg ff0000_0.3 > > to specify the same semitransparent background that I gave as an example > above. The implementation would simply check the length of the option string > and if greater than 6, parse the first 6 as hex, check for the underscore, > and parse the remainder as a floating point value. Please comment _soon_ if > you forsee any trouble with that implementation idea. > > Of course, our current semitransparent background results look rather dull > because linux applications still are not as transparency aware as they > should be, and therefore, they currently tend to impose opaque backgrounds > of their own upon which the PLplot background is superimposed. To sort out > which background is which, you can sometimes specify a background colour for > the application. For example, the ImageMagick "display" application has the > -background option to specify an opaque colour for their background, and I > was able to use that "display" option to prove that _our_ background > transparency was working correctly for the gd, cairo, and svg devices. (Of > course, it would be nice if the "display" background could be > semi-transparent as well so I hope some ImageMagick developer is working on > that.) > > In the future, as Linux and other OS's become completely transparency aware, > I can forsee our semi-transparent background capability allowing for some > really cool effects such as superimposing our plots on top of other images > or just on top of the general desktop behind where one of our plots is > displayed. Anyhow, that was the motivation for the latest commit and will > also be the motivation for the planned change to the -bg command-line option. > > 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 > __________________________ > > ------------------------------------------------------------------------------ > 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 > Plp...@li... > https://lists.sourceforge.net/lists/listinfo/plplot-devel > |
From: Alan W. I. <ir...@be...> - 2009-07-30 20:34:45
|
On 2009-07-30 14:16+0100 Alban Rochel wrote: > Dear Alan and PLplot community, > > Please find attached an update for the Qt driver, allowing changes to > the background colors (supporting transparency), based on svn revision > 10819. Hi Alban: I have committed your patch (revision 10192). My tests of the qtwidgets, pngqt, epsqt, and svgqt devices looked good for semi-transparent backgrounds specified with -bg. Also, C example 16 now gives the correct results. Thanks very much for this fix. Note, there has been a minor background regression introduced for extqt by your changes; if you run ./qt_example, then the first time you try one of "Curves" or "Histogram" the result is background colour that is the same as the underlying widget colour (gray). Subsequent tries of Curves or Histogram give you the correct (default) black background. Whether or not you can fix that minor issue, could you also implement command-line parsing for qt_example so we can thoroughly and conveniently test various colour options (e.g., -bg, -cmap0, and -cmap1)? That just means inserting the appropriate call to plparseopts in the correct place, but when I attempted to do that simple enhancement myself, I kept running up against C++ issues I didn't understand. 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: Alban R. <a.r...@im...> - 2009-07-31 10:50:58
Attachments:
qt_patch.gz
|
Alan W. Irwin wrote: > On 2009-07-30 14:16+0100 Alban Rochel wrote: > > >> Dear Alan and PLplot community, >> >> Please find attached an update for the Qt driver, allowing changes to >> the background colors (supporting transparency), based on svn revision >> 10819. >> > > Hi Alban: > > I have committed your patch (revision 10192). My tests of the qtwidgets, > pngqt, epsqt, and svgqt devices looked good for semi-transparent backgrounds > specified with -bg. Also, C example 16 now gives the correct results. > > Thanks very much for this fix. > > Note, there has been a minor background regression introduced for extqt by > your changes; if you run ./qt_example, then the first time you try one of > "Curves" or "Histogram" the result is background colour that is the same as > the underlying widget colour (gray). Subsequent tries of Curves or Histogram > give you the correct (default) black background. > > Whether or not you can fix that minor issue, could you also implement > command-line parsing for qt_example so we can thoroughly and conveniently > test various colour options (e.g., -bg, -cmap0, and -cmap1)? That just > means inserting the appropriate call to plparseopts in the correct place, > but when I attempted to do that simple enhancement myself, I kept running up > against C++ issues I didn't understand. > > 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 > __________________________ > Hi Alan, Here is a big patch for all the Qt-related stuff, based on revision 10192: - It fixes the issue you've just raised - It cleans up a little bit the code (including changing tabs into spaces, which results in a patch replacing all the code) - QtWidget and ExtQt plot faster (1), especially when plotting x/y rectangular filled shapes (2). Example x20c is now *much* faster. These are all the changes that I intended to do, so unless issues or missing features are noticed, I don't plan other updates. Cheers, Alban (1) - The buffer stores pointers to Qt plot primitives rather than the data used to generate them at every plot (e.g QRect* rather than struct holding x, y, width and height). I feared that this would consume more memory, but this is barely noticeable if at all in the end. - Colours are now only stored at colour changes, not associated to every primitive any more (2) - We used to use pens to draw the rectangles outlines, which is wrong as it adds width, and makes drawing much slower - Disabling of antialiasing for these primitives, as this could result in thin "gaps" between tiles, producing Moire patterns |
From: Alan W. I. <ir...@be...> - 2009-07-31 18:54:30
|
On 2009-07-31 11:49+0100 Alban Rochel wrote: > Alan W. Irwin wrote: >> Note, there has been a minor background regression introduced for extqt by >> your changes; if you run ./qt_example, then the first time you try one of >> "Curves" or "Histogram" the result is background colour that is the same as >> the underlying widget colour (gray). Subsequent tries of Curves or Histogram >> give you the correct (default) black background. >> >> Whether or not you can fix that minor issue, could you also implement >> command-line parsing for qt_example so we can thoroughly and conveniently >> test various colour options (e.g., -bg, -cmap0, and -cmap1)? That just >> means inserting the appropriate call to plparseopts in the correct place, >> but when I attempted to do that simple enhancement myself, I kept running up >> against C++ issues I didn't understand. > Hi Alan, > > Here is a big patch for all the Qt-related stuff, based on revision 10192: > - It fixes the issue you've just raised > - It cleans up a little bit the code (including changing tabs into > spaces, which results in a patch replacing all the code) > - QtWidget and ExtQt plot faster (1), especially when plotting x/y > rectangular filled shapes (2). Example x20c is now *much* faster. > > These are all the changes that I intended to do, so unless issues or > missing features are noticed, I don't plan other updates. Hi Alban: I split your big patch into two commits for more clarity about what you did. Revision 10195 is your patch without the whitespace changes and revision 10196 completes your patch with the (extensive) whitespace changes. Since this patch changes a lot (even if you discount the whitespace changes), I have given it a thorough testing by running both "make test_interactive" and "make test_noninteractive" in the installed examples using the new build system there. These tests were all done with the downloaded Qt4.5.1 SDK. For the test_interactive case I looked carefully at all the qtwidget results for all our examples and the qt_example result. For -dev qtwidget all seems well except that device still treats example 17 in a "noninteractive" way. I have written you separately about that issue. I also noticed your solution to the initial background colour for qt_example plus the different background color you have imposed for the Curves plot. One additional issue for qt_example is I would really like to see access to the PLplot command-line arguments for that example. To make that happen, a call to plparseopts should be inserted just before the call of plinit(); in qt_PlotWindow.cpp. However, the typical plparseopts call, e.g., plparseopts( &argc, argv, PL_PARSE_FULL ); doesn't work because there is no access (as far as I can tell) to argc and argv at that place in the code. Could you advise on how to get that access? For the test_noninteractive case, I used the ImageMagick "display" application to look at all 1040 (!) files generated by each of the qt non-interactive devices for each of the pages of our standard examples. I may have missed something because that is _a lot_ of viewing, but everything looked fine. 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: Alban R. <a.r...@im...> - 2009-08-03 07:52:36
|
Alan W. Irwin wrote: > Hi Alban: > > I split your big patch into two commits for more clarity about what you did. > Revision 10195 is your patch without the whitespace changes and revision > 10196 completes your patch with the (extensive) whitespace changes. > > Since this patch changes a lot (even if you discount the whitespace > changes), I have given it a thorough testing by running both "make > test_interactive" and "make test_noninteractive" in the installed examples > using the new build system there. These tests were all done with the > downloaded Qt4.5.1 SDK. > > For the test_interactive case I looked carefully at all the qtwidget results > for all our examples and the qt_example result. For -dev qtwidget all seems > well except that device still treats example 17 in a "noninteractive" way. I > have written you separately about that issue. I also noticed your solution > to the initial background colour for qt_example plus the different > background color you have imposed for the Curves plot. > > One additional issue for qt_example is I would really like to see access to > the PLplot command-line arguments for that example. To make that happen, > a call to plparseopts should be inserted just before the call of > plinit(); in qt_PlotWindow.cpp. However, the typical plparseopts call, > e.g., > > plparseopts( &argc, argv, PL_PARSE_FULL ); > > doesn't work because there is no access (as far as I can tell) to argc and > argv at that place in the code. Could you advise on how to get that access? > > For the test_noninteractive case, I used the ImageMagick "display" > application to look at all 1040 (!) files generated by each of the qt > non-interactive devices for each of the pages of our standard examples. I > may have missed something because that is _a lot_ of viewing, but everything > looked fine. > > 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 > __________________________ > Hi Alan, Thanks for your feedback, and good luck with your image comparisons :) I put these issues as well as the clearWidget/FLUSH remarks on my to-do list and I will come back with a patch a little later. Alban |
From: Alan W. I. <ir...@be...> - 2009-08-04 20:42:22
|
On 2009-07-31 11:49+0100 Alban Rochel wrote: [...] > - QtWidget and ExtQt plot faster (1), especially when plotting x/y > rectangular filled shapes (2). Example x20c is now *much* faster. [...] > (1) - The buffer stores pointers to Qt plot primitives rather than the > data used to generate them at every plot (e.g QRect* rather than struct > holding x, y, width and height). I feared that this would consume more > memory, but this is barely noticeable if at all in the end. > - Colours are now only stored at colour changes, not associated to every > primitive any more > (2) - We used to use pens to draw the rectangles outlines, which is > wrong as it adds width, and makes drawing much slower > - Disabling of antialiasing for these primitives, as this could result > in thin "gaps" between tiles, producing Moire patterns I have recently been doing some interactive testing, and I have to comment on the outstanding speed obtained with the new version of qtwidget. Here are some timing comparisons for example 8, but other examples also show these type of qualitative results. software@raven> time c/x08c -dev xwin real 0m0.769s user 0m0.152s sys 0m0.072s software@raven> time c/x08c -dev qtwidget real 0m0.974s user 0m0.624s sys 0m0.016s software@raven> time c/x08c -dev xcairo real 0m3.031s user 0m1.232s sys 0m0.084s I held down the enter key to autorepeat as rapidly as possible through the various pages of the example in each case so I believe the "real" times are reliable even though in each case they are substantially larger than the sum of user + sys time (presumably because of different waits for system resources required by the three different methods used here for generating the results). Focussing just on the real times, the qtwidget speed is outstanding considering all the extra font rendering and antialiasing work it does to make nice looking results compared to -dev xwin in roughly the same amount of time. -dev xcairo has similar nice looking results as qtwidget, but it takes roughly three times longer to render the result. That's interesting, but I don't think that is a major xcairo concern since I believe developers should not optimize unless there is an order of magnitude or so to be gained, and that is clearly not the case here. I was curious about the speed of qtwidget in the old days and here is one result I posted to this list in late April. software@raven> time c/x08c -dev qtwidget real 0m5.423s user 0m3.432s sys 0m0.132s Obviously, there has been more than 5 times improvement in qtwidget speed since then. Thanks, Alban! 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: Alban R. <a.r...@im...> - 2009-08-05 08:27:37
|
Alan W. Irwin wrote: > On 2009-07-31 11:49+0100 Alban Rochel wrote: > > I have recently been doing some interactive testing, and I have to comment > on the outstanding speed obtained with the new version of qtwidget. Here are > some timing comparisons for example 8, but other examples also show these > type of qualitative results. > > software@raven> time c/x08c -dev xwin > > real 0m0.769s > user 0m0.152s > sys 0m0.072s > > software@raven> time c/x08c -dev qtwidget > > real 0m0.974s > user 0m0.624s > sys 0m0.016s > > software@raven> time c/x08c -dev xcairo > > real 0m3.031s > user 0m1.232s > sys 0m0.084s > > I held down the enter key to autorepeat as rapidly as possible through the > various pages of the example in each case so I believe the "real" times are > reliable even though in each case they are substantially larger than the sum > of user + sys time (presumably because of different waits for system > resources required by the three different methods used here for generating > the results). > > Focussing just on the real times, the qtwidget speed is outstanding > considering all the extra font rendering and antialiasing work it does to > make nice looking results compared to -dev xwin in roughly the same amount > of time. -dev xcairo has similar nice looking results as qtwidget, but it > takes roughly three times longer to render the result. That's interesting, > but I don't think that is a major xcairo concern since I believe developers > should not optimize unless there is an order of magnitude or so to be > gained, and that is clearly not the case here. > > I was curious about the speed of qtwidget in the old days and here is > one result I posted to this list in late April. > > software@raven> time c/x08c -dev qtwidget > > real 0m5.423s > user 0m3.432s > sys 0m0.132s > > Obviously, there has been more than 5 times improvement in qtwidget speed > since then. Thanks, Alban! > > 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 > __________________________ > Alan, Thanks for this analysis, it's good to see that the driver is roughly on par with if not faster than others. I've measured improvements up to 40 times on spectrograms (thousands of rectangles), and interestingly the speed gains were greater on Windows than on Linux (on my test systems). As I mentioned, part of this gain was due to using x/y rectangle primitives rather than polygons where applicable. I believe most drivers could gain speed if PLplot provided a plfillrect function for such primitives. For example, plimage ends up calling plfill to create hundreds of polygons which are finally rectangles, which could be handled much faster than plain polygons. Just an idea, I don't know if it would be worth the effort, and I may have overlooked some issues. Cheers, Albam |