[Interest] cpputest with QTest output issue on embedded target console

[Ramakanth Kesireddy]

Hi,

When unit test binary(using cpputest to run the testcases + QTest for the
specific Qt functionality)is executed on embedded target(linux), it doesnot
shows any test summary/results with respect to number of testcases run on
console.

There is no issue when it is run on Ubuntu linux.

Whether Qt redirects the standard output or any environment variable to see
the output on console or any other reason?

Any thoughts on the same?

Thanks and Regards,
Ramakanth
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] Klocwork errors in Qt

[Ramakanth Kesireddy]

Thanks for all the suggestions. Atleast we are not using auto for the
concatenation of QStrings.

On Thu, Dec 5, 2019 at 2:33 PM Giuseppe D'Angelo via Interest <
interest@qt-project.org> wrote:

> Il 05/12/19 00:54, Thiago Macieira ha scritto:
> > Same issue (dangling pointer), no "auto" required.
>
> Or
>
> > QStringView f() {
> >   QString s("hello");
> >   return s;
> > }
>
> Or even
>
> > QVector v;
> > v << QString("world");
>
> etc.
>
> Really, one can build countless examples where Modern C++ will gladly
> make you shoot in your own foot...
>
> Thanks,
> --
> Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer
> KDAB (France) S.A.S., a KDAB Group company
> Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com
> KDAB - The Qt, C++ and OpenGL Experts
>
> ___
> Interest mailing list
> Interest@qt-project.org
> https://lists.qt-project.org/listinfo/interest
>
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] Tricks to improve moc performance?

[Henry Skoglund]

On 2019-12-06 02:09, Adam Light wrote:
We have several machines running Windows 10 that are quite powerful 
(eg. 8 or 16 core (16 or 32 thread) processors, lots of RAM, NVMe SSD 
storage). However, since upgrading to Windows 1903, we have noticed 
that sometimes the compile time of our large Qt 5.12 based application 
increases dramatically.


As an example, on one 16 core/32 thread machine, a debug build can 
take as little as 4 minutes. However it sometimes takes 18 minutes. 
This is for the exact same code, compiler, settings, etc. I can 
literally do a full build that takes 4 minutes, do something, delete 
the build directory and rebuild and now it takes 16 minutes. The "do 
something" may be going to lunch or making a trivial change in the 
code. Otherwise the state of the machine is the same (no other 
heavyweight processes running, etc.)


We see this behavior both when using Qt Creator 4.10.2 to do the build 
(using jom.exe) and also when done outside of Creator with calls to 
qmake and then jom. All files involved in anything I mention here are 
on and/or written to the local SSD. I see these issues with no 
antivirus running, no backup, etc.



...
Does anyone else have any ideas of how we could change our build to 
improve moc performance when Windows decides to be "slow"? Like, for 
example, is there any way to have the moc calls run with only a few 
moc processes running at once but have the rest of the build done with 
all threads running. I'm pretty sure that the OS slowdown has 
something to do with thread contention of some sort.


If anyone thinks they have run into this situation or is intimately 
familiar with Windows minifilter drivers, I'm happy to share the 
details behind why I think they are involved here.


Thanks for any ideas
Adam



Hi, just guessing, but it could be network related. For a quick test, 
when you experience that slowdown, try pulling out the network cable 
from the PC and see if the build time changes.


For a more elaborate test, consider moving your Windows build PC into 
the virtual realm, say like this: Use Disk2vhd 
https://docs.microsoft.com/en-us/sysinternals/downloads/disk2vhd to 
migrate your C: into a .vhd file. Install Ubuntu 19.10 on the PC and 
VirtualBox (or VMWare Workstation player, also free). Then load up the 
.vhd file into Ubuntu and, in my case, that combo (a virtual Windows 
running inside Ubuntu) builds faster than my vanilla Windows 10 ever did.


This year when 1903 arrived I saw some changes as well, the boot/startup 
time is better but I felt it was slower in general than 1809. So I dug 
up an old Windows 7 DVD and installed it into VMWare and reinstalled Qt 
on that Windows 7. Upgrading from Windows 10 to Windows 7 made jom happy 
again. So while it's impossible today to find a new PC that you can 
install Windows 7 on, it is still very much possible on VirtualBox or 
VMWare. Finally, since Microsoft will cease support of Windows 7 next 
month, make sure *never* to browse the internet or do your email from 
Windows 7, always use Ubuntu.


Rgrds Henry

___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

[Interest] QOpenGLWidget strokes premul, while QWidget is straight?

[David M. Cotter]

referring to this article 
,
 i see someone else has also run into this, but did not get a satisfactory 
answer.

I am implementing what on macOS Carbon is known as a "transparency layer", that 
is, you begin a transparency context, do your drawing (with transparency), 
finish your context, then blit the contents of that context as a whole with a 
specified transparency (this is to achieve "fade away" via animation).

When i use QWidget, my stroked paths (text) look creamy smooth along the edges, 
as if everything is in fact being handled as straight alpha:


However, if i switch to using QOpenGLWidget, my stroked paths appear to have a 
crusty border, as if they were drawn with premul-over-black alpha:


No other code changes except swapping QOpenGLWidget for QWidget.

Does this seem... unexpected? Note if i attempt to manually unmultiply, things 
look much worse, so i don't think it's PRECISELY a premul thing. (and i know my 
manual unmultiply works because unit tests)

(Ignore for now the fact that it's white-on-white, i know that, i'm NOT drawing 
the black text behind the stroke to more clearly illustrate the halo around the 
strokes)

-dave___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

[Interest] Tricks to improve moc performance?

[Adam Light]

We have several machines running Windows 10 that are quite powerful (eg. 8
or 16 core (16 or 32 thread) processors, lots of RAM, NVMe SSD storage).
However, since upgrading to Windows 1903, we have noticed that sometimes
the compile time of our large Qt 5.12 based application increases
dramatically.

As an example, on one 16 core/32 thread machine, a debug build can take as
little as 4 minutes. However it sometimes takes 18 minutes. This is for the
exact same code, compiler, settings, etc. I can literally do a full build
that takes 4 minutes, do something, delete the build directory and rebuild
and now it takes 16 minutes. The "do something" may be going to lunch or
making a trivial change in the code. Otherwise the state of the machine is
the same (no other heavyweight processes running, etc.)

We see this behavior both when using Qt Creator 4.10.2 to do the build
(using jom.exe) and also when done outside of Creator with calls to qmake
and then jom. All files involved in anything I mention here are on and/or
written to the local SSD. I see these issues with no antivirus running, no
backup, etc.

I have collected some Windows Performance Tracing traces while building and
during a "slow" build, most of the time is spent in moc, specifically
searchIncludePaths. This function results in a lot of calls to
QFileInfo::exists() and QFileInfo::isDir(), both of which ultimately call
GetFileAttributesExW. The vast majority of the time is spent in downstream
calls that GetFileAttributesExW makes, so I am not blaming moc itself for
the slowdown.

I don't want to get too much into the weeds, but I believe that the
slowdown is a bug in one or more Windows minifilter drivers, which get
invoked by the OS in the file API calls. I suspect that pinpointing the
problem in such a way that I could report it to Microsoft is unlikely, and
so for practical reasons I am hoping that there is a way we could change
our build process to work around this slowdown.

Our application is one that was ported into Qt and we are building a few
very small libraries and one gigantic application that links to those
libraries. This isn't ideal, I'm sure, but I don't think it would be
practical to disentangle everything to have separate projects that are
first built and then linked into the main application.

We have almost 600 classes that use Q_OBJECT, so there are a lot of calls
to moc. We probably don't strictly need the Q_OBJECT macro in some of those
classes, but I would prefer not to start removing Q_OBJECT unless that's
the last option.

We also have around 200 paths in our INCLUDEPATH variable. Moving header
files into fewer directories would allow that to decrease, which should
improve moc performance.

Does anyone else have any ideas of how we could change our build to improve
moc performance when Windows decides to be "slow"? Like, for example, is
there any way to have the moc calls run with only a few moc processes
running at once but have the rest of the build done with all threads
running. I'm pretty sure that the OS slowdown has something to do with
thread contention of some sort.

If anyone thinks they have run into this situation or is intimately
familiar with Windows minifilter drivers, I'm happy to share the details
behind why I think they are involved here.

Thanks for any ideas
Adam
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] Klocwork errors in Qt

[Giuseppe D'Angelo via Interest]

Il 05/12/19 00:54, Thiago Macieira ha scritto:

Same issue (dangling pointer), no "auto" required.


Or

QStringView f() { 
  QString s("hello");

  return s;
}


Or even


QVector v;
v << QString("world");


etc.

Really, one can build countless examples where Modern C++ will gladly 
make you shoot in your own foot...


Thanks,
--
Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer
KDAB (France) S.A.S., a KDAB Group company
Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com
KDAB - The Qt, C++ and OpenGL Experts



smime.p7s
Description: Firma crittografica S/MIME
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest