On Thu, Dec 27, 2018 at 2:38 AM Alan W. Irwin <alan.w.irwin1...@gmail.com> wrote:
> On 2018-12-27 01:04-0000 António Rodrigues Tomé wrote: > > > Hi Alan > > you must revisit the -bg comand argument. > [...] > > P.s. > > > > may it be that the -bg argument is only called after the device > constructor > > has been valled? > > Nope, the -bg option works well normally. But you were right I had to > revisit that option because in this case I screwed up the format of > that option. Sorry about that! > > Note to self: add a warning message from the -bg option if > a background colour is specified using a bad format (such as forgetting > the underscore between RGB colours and alpha value like I just did). > > Here is an example with the correct -bg format > > examples/c/x30c -dev pngqt -o test3_qt.png -fam -bg 00F_0.3 > > (note the underscore in the -bg option!). This works properly with your > revised code and produces a "fake" checkerboard background for both > "display" and "pqiv" image viewer applications indicating both applications > detected a semi-transparent background. Note also the size of the > checkerboard blocks in the two cases is different confirming those are > different artifacts added by these two applications (i.e., not > something added by the PLplot code or Qt library). > > I have attached test3_qt.png.1 generated by the above command for > your fixed case. Please let me know whether or not that gives > the same results as your platform with whatever image viewer > you are using to view that file. > > I also confirmed that I don't get the checkerboards for the two > image viewing apps if I run > > examples/c/x30c -dev pngqt -o test4_qt.png -fam -bg 00F_0.3 > > without your fix. > > So your code fix appears to be good, but only seems to affect the > background > for some reason. But for the commit message I still need your best > speculation (or Qt documentation reference if you have that) as to > *why* that is the case and also *why* the old version of the > code appeared to work OK for background opaque colours without > the extra call to the fill method that you have put in now. > > So to address these commit message issues please respond to my > previous questions about why ARGB32 is necessary in order to get the > background to work but RGB32 seems to be fine for our unmodified code > for the other transparency rendering that occurs, in, e.g., example > 30. And please also respond to my question about why you think that > opaque backgrounds but not semi-transparent background worked before > you added the extra call to the fill method. > Hi Alan. Let start by saying that my English sucks. I've never learn it when I was young only latter on on life I've learned some english reading math and physics text books. So the option ARGB32 seemed logical but the reason I changed it was because RGB32 did not work. So let me just copy a text from a link I had send you earlier "...Think of fill with alpha as a merge operation and not a replace. I was thinking of it as a replace and therefore I was replacing every pixel with a fully transparent black. However, because fillRect is really a merge I was merging a transparent pixel with the background effectively doing nothing..." so if you have already a background and fill with a alpha brush you are in fact doing a merge operation and probably the result is the above layer acted as if it was semi transparent . The problem is for the background you have to have something to merge if you start a background with a color you never get a transparency. If you merge with alpa=0 you get the original background. That's the reason for completely set the background at the device constructor to transparent before doing anything else. And if we are in fact doing merge operations (only when alpha is involved) this will not interfere when one uses solid colors. with your correct -bg option I get exactly what you got. Although files binary differ but I attach a screenshot with your file side by side with my cheers > > The reason for putting this sort of detail in your commit messages, is > it is really helpful if someone runs "git blame > bindings/qt_gui/plqt.cpp" 10 years from now (by the way, you should > run that command for yourself right now to see what it does), spots > the commit associated with your change and then looks at the > corresponding git log message to help figure out what was on your mind > when you made the change you did. (I use that technique all the time > now to figure out why previous code changes were done.) > > Of course, if you found the combination of changes that worked by > simply trying some experiments, (i.e., you have no idea why this > change works) then state that. But I expect this fix was based on > something specific in your Qt knowledge so that is what I need from > you. > > And to finish your part in getting this change pushed, please state > whatever tests you ran (in sufficient detail that I could replicate > those for myself) so I can append that information to the "Tested by:" > paragraph for you. > > Alan > __________________________ > Alan W. Irwin > > 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 > __________________________ -- António Rodrigues Tomé Universidade da Beira Interior Instituto D. Luís (lab associado) email address: art...@gmail.com art...@ubi.pt http://www.researcherid.com/rid/A-5681-2013
_______________________________________________ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
