Hi Alan
glad things have solved out. You gave a full explanation my approach was
more intuitive.
as for testing I haven't performed nothing formal. in fact I have a qt gui
application with the ex01c and i usually play with it to figure things up.
Not a standard plplot way of doing things
but here the output of valgrind --leak-check=full ./x30c -dev pngqt -o
test3mine_qt.png -fam -bg 00F_0.3.
only the sUmary
LEAK SUMMARY:
==2484== definitely lost: 1,668 bytes in 21 blocks
==2484== indirectly lost: 176 bytes in 3 blocks
==2484== possibly lost: 0 bytes in 0 blocks
==2484== still reachable: 424,916 bytes in 1,715 blocks
==2484== suppressed: 0 bytes in 0 blocks
but when looking for all the report most of things are related with qt
libraries or system libraries a few things related with plplot.
however nothing related with the changes as essentially they are in qt.o
and also in and was not changed in this commit (I'm using also a version
where i do not change the qt.cpp)
if you found it useful here the details of my system
Operating System: openSUSE Leap 15.0
KDE Plasma Version: 5.14.4
Qt Version: 5.12.0
KDE Frameworks Version: 5.53.0
Kernel Version: 4.12.14-lp150.12.28-default
OS Type: 64-bit
Processors: 4 × Intel® Core™ i5-3330 CPU @ 3.00GHz
Memory: 7.7 GiB of RAM
As for the another important change to allow all qt drivers to be called
from within a qt application I think your worries are not justifiable as
the function I changed is not called when an extqt is used.
my change
if(appCounter == 1 && qApp != NULL) ++appCounter; //This was added to
allow qt drivers to be called from within a qt program.
is in function initQtApp
that is called by
plD_init_rasterqt
plD_init_svgqt
plD_init_epspdfqt
plD_init_qtwidget
plD_init_memqt
is not called by
plD_init_extqt
as this driver is, as I understand to be called from within a qt
application so does not try to open another qApp.
cheers
On Thu, Dec 27, 2018 at 12:54 PM Alan W. Irwin <alan.w.irwin1...@gmail.com>
wrote:
> On 2018-12-27 08:58-0000 António Rodrigues Tomé wrote:
>
> [...]
> > 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.
>
> Hi António:
>
> Actually, I admire your ability to pick up completely understandable
> written English later on in life since even as a young man I had
> trouble with attempting to learn even one non-English language, and my
> own written English is the result of hard work and lots of re-editing
> even the most trivial e-mails and not something that is easy for me.
>
> Anyhow, your explanation about what is going on with Qt (including
> your additional P.S. post) gave me enough clues to find further
> documentation and articles. So using "git commit --amend" simply to
> modify the commit message for your commit according to that new
> knowledge, here is how that message reads now:
>
> -----------------------------8<---------------------------
> software@merlin> git log --name-status -1 |cat -
> commit 8612dc30bdd6aa5bf3026c5b130206efb5df895c
> Author: António R. Tomé <antoniort...@users.sourceforge.net>
> Date: Mon Dec 24 14:58:00 2018 +0000
>
> Fix background transparency bug in the qt raster devices
>
> We found experimentally that QtRasterDevice::QtRasterDevice required
> the following two changes to solve a long-standing bug where the alpha
> value of the background was being completely ignored by qt raster
> devices (so semi-transparent backgrounds were being rendered as
> completely opaque):
>
> 1. Change the QImage format of results for raster devices from
> QImage::Format_RGB32 to QImage::Format_ARGB32. This change (or
> possibly changing to the QImage::Format_ARGB32_Premultiplied format in
> the future for efficiency reasons) is required because the
> QImage::Format_RGB32 documentation at
> <http://doc.qt.io/qt-5/qimage.html#Format-enum> states "The image is
> stored using a 32-bit RGB format (0xffRRGGBB)" i.e., the alpha channel
> is completely fixed at opaque. So this previously adopted opaque
> format was not correct.
>
> 2. Insert a transparent fill canvas (with color Qt::transparent which
> is transparent black according to
> <http://doc.qt.io/qt-5/qt.html#GlobalColor-enum> as the first layer
> of
> the image. Transparent black is essential since the normal "over"
> compositing rule (see the compositing formula in
> <https://en.wikipedia.org/wiki/Alpha_compositing> which composites
> the
> semi-transparent PLplot background on top of that transparent black
> canvas gives a result which is exactly the PLplot background, with
> unchanged ARGB values.
>
> Tested by: António R. Tomé <antoniort...@users.sourceforge.net> on
> Linux
> (openSUSE leap 15.0) by ???
>
> Tested by: Alan W. Irwin <air...@users.sourceforge.net> on Linux
> (Debian Testing) by building the x30c and qt targets and running
>
> valgrind examples/c/x30c -dev pngqt -o test3_qt.png -fam -bg 00F_0.3
>
> The valgrind report showed "ERROR SUMMARY: 0 errors from 0 contexts
> (suppressed: 64975 from 1)" which is a good memory management report
> aside from the memory leaks which were also mentioned (which should be
> looked at in detail later to make sure those are due to Qt library
> issues rather than qt device driver issues).
>
> When test3_qt.png was viewed with either the "display" or "pqiv" image
> viewer applications the results showed the above blue background with
> 30 per cent opacity (or 70 per cent transparency) composited with a
> black and white checkerboard canvas. Those canvases were rendered by
> the two different applications (as proved by the different sized
> squares in the two cases) as the traditional means of marking a
> semitransparent background. Previous to this fix, the checkerboards
> were not present indicating an incorrect opaque blue background.
>
> M bindings/qt_gui/plqt.cpp
> -----------------------------8<---------------------------
>
> So assuming you like what I have written above and also just as soon
> as you let me know how you tested this commit (see the ??? above in
> this commit message that still needs to be filled in by you), I will
> push it.
>
> 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
