Just an update. qt drivers do not behave well with alfa values. as the background was being filled with the instruction
QBrush brush( QColor( r, g, b, (int) ( alpha * 255 ) ) ); m_painterP->fillRect( 0, 0, width(), height(), brush ); however has explained in http://curtis.humphreyonline.us/code/qt-code/making-a-qpixmap-transparent-wrong-way-right-way things are esaily solved if in QtRasterDevice::QtRasterDevice( int i_iWidth, int i_iHeight ) : QImage::Format_RGB32 is replaced by QImage::Format_ARGB32 and fill(Qt::transparent); is added in the constructor QtRasterDevice::QtRasterDevice( int i_iWidth, int i_iHeight ) : QtPLDriver( i_iWidth, i_iHeight ), QImage( i_iWidth, i_iHeight, QImage::Format_ARGB32 ) { // Painter initialised in the constructor contrary // to buffered drivers, which paint only in doPlot(). m_painterP = new QPainter( this ); fill(Qt::transparent); QBrush b = m_painterP->brush(); b.setStyle( Qt::SolidPattern ); m_painterP->setBrush( b ); m_painterP->setRenderHint( QPainter::Antialiasing, (bool) lines_aa ); } I'll try to upload this changes using git as I cannot find any other problem with qt drivers at least for the use I make of them. (well memqt does not work quite well but neither did memcairo) Have a nice Christmas On Sat, Dec 22, 2018 at 10:16 PM António Rodrigues Tomé <art...@gmail.com> wrote: > Hi Alan > I think the small change I purpose will do the trick. In no way it will > mess up with the normal functionality of the driver but it will allow all > qt drivers to be used inside a qt > program. I've tested it. > I Think Alban Rochel never considered necessary to use the drivers from a > qt program he decided that from a qt program the normal way was to use the > the qt widget driver (not acceptable in my point of view). > With the small change I made the qt-example is not affected and all the > others drivers can be called from a qt program to produce image files. > > cheers, > > > > On Sat, Dec 22, 2018 at 9:30 PM Alan W. Irwin <alan.w.irwin1...@gmail.com> > wrote: > >> On 2018-12-20 13:21-0800 Alan W. Irwin wrote: >> >> > On 2018-12-20 18:56-0000 António Rodrigues Tomé wrote: >> > >> >> Hi Alan >> >> I do not completely understand the need of using a mutex in the qt >> driver >> >> however >> >> without any change in the actual driver approach it is easy to allow >> the >> >> driver to work well within a qt app and also in any other c or c++ >> program >> >> if in the file qt.cpp function bool initQtApp( bool isGUI ) >> >> we add after the ++appCounter; line (line 90) >> >> the instruction >> >> if(appCounter == 1 && qApp != NULL) ++appCounter; >> >> this will prevent the call >> >> delete qApp; >> >> when one closes the driver within a qt application, that would crash >> teh >> >> application, and it does not conflict with the actual behavior of >> the qt >> >> driver it onnly takes account for the fact that there is a qApp that >> was >> >> not started by the driver. >> > >> > Hi António: >> [...] >> > So from the point of view of a non-expert for this code, I would >> > suggest if you think the mutex is no longer needed because of your >> > change, then go ahead an remove it to see whether that combined change >> > passes all tests you care to make including ideally running the >> > comprehensive test script as documented in >> > doc/wiki_source/Testing_PLplot. >> >> With regard to the mutex, I have included what Alban initially said about >> it way back when. >> >> From his comment my guess is the mutex is a necessity to keep the Qt >> components of PLplot thread-safe because the PLplot core is not thread >> safe (although fixing that bad state of affairs is on our long-term >> agenda). >> And subsequently there was a whole lot of plplot-devel traffic about >> properly setting up that mutex with no question from anyone about its >> necessity. >> >> Anyhow, forget my naive idea above that you might want to drop the mutex. >> >> Alan >> >> ---------- Forwarded message ---------- >> Date: Fri, 20 Mar 2009 17:00:49 +0000 >> From: Alban Rochel <a.roc...@imperial.ac.uk> >> To: Alan W. Irwin <ir...@beluga.phys.uvic.ca> >> Subject: Qt driver update >> >> Alan, >> >> I've made a break from QSAS for an hour and I've made a couple of >> improvements >> to the Qt driver. >> >> - I've introduced a mutex to make some parts thread-safe (I haven't >> checked if >> all the driver was). >> - Someone noticed that when 2 qtwidgets were running on 2 streams, >> closing them >> didn't close the driver properly. This should be fixed by now. When qApp >> is >> run, all the qtwidgets created before are tagged as being run, and so the >> driver shouldn't try to run one qApp per widget. >> >> Cheers, >> >> Alban >> >> __________________________ >> 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 > > -- 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
