Menu
▾
▴
plplot-devel
|
From: Alan W. I. <ir...@be...> - 2016-02-06 22:00:16
|
Hi Phil: Part of the overall goal of getting RGBA background images to work is to get the "A" (alpha channel) component of that to work properly, and so a preliminary goal should be to implement uniformly colored semitransparent backgrounds correctly. Some current semitransparent background issues we should be aware of: * Device driver issues: Just for a single page plot where I specify a completely transparent background, there are issues for a number of our devices. Ones that apparently do work currently are the qt devices. For example, examples/c/x00c -dev pdfqt -bg 000000_0.0 -o test.pdf does produce a transparent background for that pdf as proved by the ImageMagick "display" command rendering that transparent background as a checkerboard. But the same experiment with pdfcairo shows an opaque white background. I believe that should be considered to be a bug in the cairo devices since the fundamental principle should be if a user specifies a semitransparent background (as above), that is exactly what PLplot drivers should supply rather than substituting something else in the belief that we know better than the user! * Interactive device issues: Even though the above experiment with pdfqt demonstrates that device follows the user wishes, it is not clear that also occurs for the qtwidget device because I could not get the desired result (a completely transparent background) to work for qtwidget. Of course, that may have nothing to do with our qt device and may be related to the following compositing issue. * Desktop compositing issues: There is an ImageMagick "display" option to actually honor the transparent background request rather than replacing it with a checkboard. I cannot remember that exact option, but when I tried it years ago, the result was the plot is displayed on top of whatever your desktop would be displaying otherwise (what I call the root desktop below). But it would be cooler still if it worked for semitransparent backgrounds (as opposed to completely transparent like in the above case), but when I last tried this there were KDE/X compositing issues that didn't allow that to work properly. I have no idea whether my KDE/X desktop software has been fixed yet in this regard or not. * Multiple page issues: I can forsee the need for two modes here for those interactive cases where pages are normally just stacked on top of the previous pages with a background superimposed at the start and between each page. If that background is completely transparent, then you should see the whole stack of previous results right back to the root desktop (whatever the desktop software would be displaying if the plot GUI was not superimposed on top), and if the transparency is dropped to say 90 per cent then you will see that stack of previous results gradually fading away as you display contents from deeper in the stack to make a really cool-looking effect. So this possibility of seeing everything in the stack modified by the transparency of the superimposed backgrounds in between should be allowed, but there should also be an interactive mode that starts fresh with each page, i.e., the root desktop is displayed, then the semitransparent background, then the plot for the single page. In sum, this whole field of supporting RGBA background images for each plot page is an extremely interesting one, but to get the "A" part of that to work correctly we need to deal with the above issues that show up even when the background "RGBA image" is a simple one that is uniformly coloured. 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); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); 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 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); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); 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: Phil R. <p.d...@gm...> - 2016-02-07 13:26:02
|
Hi Alan There is plenty of cool stuff there, but remembering that plplot is a library and not an application our job should be to enable transparency and allow the user to do that cool stuff - but that might form the basis of a demo. Here is my opinion: For file output, it should just be like a transparent/semitransparent rectangle was drawn over the page as the first render object. For drivers where the user provides the canvas, things should be just as for file output. This would allow users to draw over existing items - I'm thinking, e.g. A report program that includes text and provides this dc to plplot to draw plots on too. For interactive drivers where the user does not provide the canvas I am not sure what to do. In this case I think the most appropriate thing is to ignore transparency. I don't think making the window transparent is appropriate as it will just generate lots of driver and platform dependant inconsistencies. Regarding page clears. I feel that a new page is a new page and should not show previous pages in the background. Presumably this is dealt with by new files or document pages in many cases. If users want to simulate this effect they can do so themselves using plclear calls with semitransparent background colours. I think all this will then be consistent with transparent lines and shapes rendered by other calls. Phil -----Original Message----- From: "Alan W. Irwin" <ir...@be...> Sent: 06/02/2016 22:00 To: "Phil Rosenberg" <p.d...@gm...> Cc: "Greg Jung" <gv...@gm...>; "Jim Dishaw" <ji...@di...>; "plp...@li..." <plp...@li...> Subject: Uniformly coloured semitransparent backgrounds Hi Phil: Part of the overall goal of getting RGBA background images to work is to get the "A" (alpha channel) component of that to work properly, and so a preliminary goal should be to implement uniformly colored semitransparent backgrounds correctly. Some current semitransparent background issues we should be aware of: * Device driver issues: Just for a single page plot where I specify a completely transparent background, there are issues for a number of our devices. Ones that apparently do work currently are the qt devices. For example, examples/c/x00c -dev pdfqt -bg 000000_0.0 -o test.pdf does produce a transparent background for that pdf as proved by the ImageMagick "display" command rendering that transparent background as a checkerboard. But the same experiment with pdfcairo shows an opaque white background. I believe that should be considered to be a bug in the cairo devices since the fundamental principle should be if a user specifies a semitransparent background (as above), that is exactly what PLplot drivers should supply rather than substituting something else in the belief that we know better than the user! * Interactive device issues: Even though the above experiment with pdfqt demonstrates that device follows the user wishes, it is not clear that also occurs for the qtwidget device because I could not get the desired result (a completely transparent background) to work for qtwidget. Of course, that may have nothing to do with our qt device and may be related to the following compositing issue. * Desktop compositing issues: There is an ImageMagick "display" option to actually honor the transparent background request rather than replacing it with a checkboard. I cannot remember that exact option, but when I tried it years ago, the result was the plot is displayed on top of whatever your desktop would be displaying otherwise (what I call the root desktop below). But it would be cooler still if it worked for semitransparent backgrounds (as opposed to completely transparent like in the above case), but when I last tried this there were KDE/X compositing issues that didn't allow that to work properly. I have no idea whether my KDE/X desktop software has been fixed yet in this regard or not. * Multiple page issues: I can forsee the need for two modes here for those interactive cases where pages are normally just stacked on top of the previous pages with a background superimposed at the start and between each page. If that background is completely transparent, then you should see the whole stack of previous results right back to the root desktop (whatever the desktop software would be displaying if the plot GUI was not superimposed on top), and if the transparency is dropped to say 90 per cent then you will see that stack of previous results gradually fading away as you display contents from deeper in the stack to make a really cool-looking effect. So this possibility of seeing everything in the stack modified by the transparency of the superimposed backgrounds in between should be allowed, but there should also be an interactive mode that starts fresh with each page, i.e., the root desktop is displayed, then the semitransparent background, then the plot for the single page. In sum, this whole field of supporting RGBA background images for each plot page is an extremely interesting one, but to get the "A" part of that to work correctly we need to deal with the above issues that show up even when the background "RGBA image" is a simple one that is uniformly coloured. 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); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); 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 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); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); 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...> - 2016-02-07 20:19:03
|
On 2016-02-07 13:25-0000 Phil Rosenberg wrote: > There is plenty of cool stuff there, but remembering that plplot is a library and not an application our job should be to enable transparency and allow the user to do that cool stuff - but that might form the basis of a demo. Agreed. > For file output, it should just be like a transparent/semitransparent rectangle was drawn over the page as the first render object. Agreed, but I believe that is the current model in any case, i.e., it is a bug if a file device does not follow that model. > For drivers where the user provides the canvas, things should be just as for file output. This would allow users to draw over existing items - I'm thinking, e.g. A report program that includes text and provides this dc to plplot to draw plots on too. Agreed. > For interactive drivers where the user does not provide the canvas I am not sure what to do. In this case I think the most appropriate thing is to ignore transparency. I don't think making the window transparent is appropriate as it will just generate lots of driver and platform dependant inconsistencies. I do agree that just as with the IM display GUI, there would be external factors (such as bad compositing for your desktop display) that might or might not allow this to work, but sometimes it does work (i.e., the user can get a cool effect where they create an interactive plot on a semitransparent background where they could see through the plot to some details from the underlying desktop). This already happens for the display of file devices (at least those which conform to the above model). So if users have this desire, I don't think our library should get in the way just in case the user has external factors that allow this to work. And I don't think there is much downside to this approach; that is "not working due to external factors" here means that the background is opaque or a checkerboard rather than the plot does not work at all. > Regarding page clears. I feel that a new page is a new page and should not show previous pages in the background. Presumably this is dealt with by new files or document pages in many cases. If users want to simulate this effect they can do so themselves using plclear calls with semitransparent background colours. You are right. So never mind on that idea of mine of overlaying pages together with semintransparent background between. So I now think the interactive model should be that there is a canvas provided which could be an opaque rectangle of a given color, an image, text, or even (I argue above) the current desktop display. Anyhow, our library should not care a bit about the nature of that canvas and for each interactive page it should simply start with that canvas, lay down a semitransparent background, and then render the rest of the plot commands for the page. My impression is that currently our interactive device drivers don't follow this model at all for multiple pages and instead simply render a background (on the incorrect assumption it is always opaque) to overlay previous pages. So moving from this model to the one above is going to be a significant amount of work for each device driver, but I think such work would be extremely worthwhile if we come to consensus that the above interactive model is what we want. 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); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); 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: Phil R. <p.d...@gm...> - 2016-02-08 10:44:24
|
> I do agree that just as with the IM display GUI, there would be > external factors (such as bad compositing for your desktop display) > that might or might not allow this to work, but sometimes it does work > (i.e., the user can get a cool effect where they create an interactive > plot on a semitransparent background where they could see through the > plot to some details from the underlying desktop). This already > happens for the display of file devices (at least those which conform > to the above model). So if users have this desire, I don't think our > library should get in the way just in case the user has external > factors that allow this to work. And I don't think there is much > downside to this approach; that is "not working due to external > factors" here means that the background is opaque or a checkerboard > rather than the plot does not work at all. > > So I now think the interactive model should be that there is a canvas > provided which could be an opaque rectangle of a given color, an > image, text, or even (I argue above) the current desktop display. > Anyhow, our library should not care a bit about the nature of that > canvas and for each interactive page it should simply start with that > canvas, lay down a semitransparent background, and then render the > rest of the plot commands for the page. > > My impression is that currently our interactive device drivers don't > follow this model at all for multiple pages and instead simply render > a background (on the incorrect assumption it is always opaque) to > overlay previous pages. So moving from this model to the one above is > going to be a significant amount of work for each device driver, but I > think such work would be extremely worthwhile if we come to consensus > that the above interactive model is what we want. > The wxWidgets drivers certainly does as you say - it's response to plclear is to simply draw a rectangle of the appropriate colour. If that colour was transparent then I think we end up drawing over some default window background which I think is black, but I'm not sure - perhaps it depends on the window type, and it may even be unassigned memory. I can go with the idea of transparent windows - I have just checked and wxWidgets does have the capability to do transparent windows - we will see how well tested that code is I guess. Would you be interested in writing an example (prefereably multipaged) Alan? Perhaps this could just be one of the existing examples with a transparent background or a flag for transparent backgrounds. I will then try and get the wxWidgets driver to do as it should for that example. |
|
From: Alan W. I. <ir...@be...> - 2016-02-08 11:52:58
|
On 2016-02-08 10:44-0000 Phil Rosenberg wrote: > The wxWidgets drivers certainly does as you say - it's response to > plclear is to simply draw a rectangle of the appropriate colour. If > that colour was transparent then I think we end up drawing over some > default window background which I think is black, but I'm not sure - > perhaps it depends on the window type, and it may even be unassigned > memory. > > I can go with the idea of transparent windows - I have just checked > and wxWidgets does have the capability to do transparent windows - we > will see how well tested that code is I guess. > > Would you be interested in writing an example (prefereably multipaged) > Alan? Perhaps this could just be one of the existing examples with a > transparent background or a flag for transparent backgrounds. I will > then try and get the wxWidgets driver to do as it should for that > example. I suggest example 9 because I know that that already works (see below). All you have to do is use the command line -bg option which is documented (using the -h command-line option) as -bg color Background color (FF0000=opaque red, 0000FF_0.1=blue with alpha of 0.1) So I tried examples/c/x08c -dev pdfqt -bg FF0000_0.0 -fam -o test.pdf I got the expected result (transparent background as indicated by a checkerboard pattern for the ImageMagick display programme) for all 5 pages of that example, i.e., test.pdf.[1-5]. In other words, transparent backgrounds are working properly for the qt file devices. On the other hand, if I run examples/c/x09c -dev qtwidget -bg FF0000_0.0 I do not get the expected result; each page had an opaque red background inserted rather than the specified transparent one. So I expect something special is being done to ignore background transparency in that particular qt device that is not done for the corresponding qt file devices. I am tied up with something else at the moment, but I will attempt to fix that in the next week or so if you don't beat me to it. Once you implement the alpha channel properly for wxwidgets backgrounds, then examples/c/x09c -dev wxwidgets -bg FF0000_0.0 should show all the pages stacked on top of each other for our current "stack of pages" interactive model (which you have advocated changing to an individual page model which I think is a good idea). But for the present interactive model if you specify some intermediate alpha like examples/c/x09c -dev wxwidgets -bg FF0000_0.2 then if the alpha channel is implemented properly for wxwidgets backgrounds, there should be "interesting" successive fading caused by each additional semitransparent layer as you look down through the stack of pages that will be displayed. 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); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); 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 __________________________ |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X