Re: [Plplot-devel] Qt5 support, strange driver output

[António R. T. <ar...@gm...>]

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 <Ala...@gm...>
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é <ant...@us...>
> 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é <ant...@us...> on
> Linux
>      (openSUSE leap 15.0) by ???
>
>      Tested by: Alan W. Irwin <ai...@us...> 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:
ar...@gm...
ar...@ub...
http://www.researcherid.com/rid/A-5681-2013