[Interest] Extremely sluggish browser performance in Qt 5.5 - [SOLVED]

[John C. Turnbull]

OK, problem (more or less) "resolved".

Joerg Bornemann commented on the issue and it turns out it is a duplicate of
another issue related to having more than one active network adapter.

My machine actually has 2 physical network adapters (one active) and also a
virtual one use by VMware Workstation.

As soon as I go into the Device Manager and disable the other 2 adapters,
the browser instantly starts to perform just like Chrome. Most importantly,
Google Maps works extremely well.

Thanks everyone!

-----Original Message-----
From: interest-bounces+ozemale=ozemail.com.au at qt-project.org
[mailto:interest-bounces+ozemale=ozemail.com.au at qt-project.org] On Behalf Of
Allan Sandfeld Jensen
Sent: Tuesday, June 23, 2015 9:20 PM
To: interest at qt-project.org
Subject: Re: [Interest] Extremely sluggish browser performance in Qt 5.5

On Tuesday 23 June 2015, Till Oliver Knoll wrote:
> > Am 23.06.2015 um 03:14 schrieb John C. Turnbull
<ozemale at ozemail.com.au>:
> > 
> > It seems that the "problem" exists in 5.4.2 as well so it's 
> > definitely not a regression.
> 
> Sorry, just a shot into the blue here. Maybe the problem has to do 
> with how Qt interacts with the underlying network stack? IPv6 setup,
maybe?
> 
> And does the problem also occur on other (Window) machines? A firewall 
> maybe which gets overly "busy" with that "unknown browser"?
> 
> What about other Qt networking (example) apps? Wasn't there once a 
> simple FTP example (I guess that's gone though, since QFtp doesn't 
> exist anymore in Qt 5 - or does it?)?
> 
> Or that QML "Flickr Image Viewer" that I have in mind? Do those Qt 
> network applications exhibit the same extreme slowness (which would 
> hint at a problem somewhere in QAbstractSocket and friends maybe)?
> 
> Are you in a "corporate network"? What if you run the application in 
> another network (preferably on the /same/ computer)? Are you sure the 
> other browsers don't use a (default system) proxy which would bring 
> the network packets "on the fast lane"?
> 
> 
> My best bet is a problem with IPv6, the rest above sorted in 
> "increasing esotheric order"...
> 
Remember you can't compare to other network-using Qt applications, since
QtWebEngine is using Chromium's network stack, not Qt's. So the question
when is the Chromium stack doing something wrong, and what is Chrome doing
differently to not hit that issue.

`Allan
_______________________________________________
Interest mailing list
Interest at qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest