QWebView - On Click CPU Performance
-
Big update -
In the .css, I have something like this -body { -webkit-user-select:none; }This is added to disable the user selection when user touches the report.
When I have removed this line from .css and test it, boom. I don't have the UI freeze issue at all.
Glad that I could get closer.
Now, I need to know, what happens when we set this property to NONE, why would it consume more CPU?
If this property won't help me, the can you please suggest other best ways to disable the user selection?
Thank you!
-
This post is deleted!
-
@kumararajas said in QWebView - On Click CPU Performance:
Now, I need to know, what happens when we set this property to NONE, why would it consume more CPU?
If this property won't help me, the can you please suggest other best ways to disable the user selection?
I don't know, sorry. Perhaps @Konstantin-Tokarev does?
If you don't find any answers here, you might have better luck asking the WebKit developers: https://webkit.org/asking-questions/
-
Qt 4.8.4 is EOL, WebKit shipped with it is forked from WebKit upstream as of 2011 so it may be seriously lacking on Web platform features and cause pages to load tons of polyfills. You may want to use QtWebKit 2.3.4 with Qt 4.8.4, it's a bit newer WebKit (2012), however there is no guarantee that it will work better.
It also can be that bad performance is caused by graphic animations on your page, in this case hardware acceleration (i.e., QGLWidget viewport and enabled AcceleratedCompositing) may help
-
@JKSH said in QWebView - On Click CPU Performance:
If you don't find any answers here, you might have better luck asking the WebKit developers: https://webkit.org/asking-questions/
Asking wague questions about 8-year old fork of WebKit on official WebKit channels would likely be a waste of everyone's time..
-
@Konstantin-Tokarev said in QWebView - On Click CPU Performance:
Asking wague questions about 8-year old fork of WebKit on official WebKit channels would likely be a waste of everyone's time..
You're right.
I didn't realize it was a fork, since it was hosted on the official repo; I thought it was just a Qt-ish interface to the official engine.
-
@JKSH said in QWebView - On Click CPU Performance:
You're right.
I didn't realize it was a fork, since it was hosted on the official repo; I thought it was just a Qt-ish interface to the official engine.
Well, it indeed was hosted in official repo, and was counted as "port", not a "fork". But there are a few things to consider:
- Qt port does a lot of things differently from other WebKit ports, e.g. it uses Qt for networking, graphics, has lots of other custom code paths
- Stable versions (both those released as a part of Qt and standalone) are technically forks, since they are based on branch starting in upstream WebKit and containing modifications on top of that
- Right now few people in WebKit community around webkit.org are aware of Qt port and its peculiarities; I'm probably the only one
Also, question in this topic is of a kind "go profile & debug it on device" - so, instead of asking on forums, author should either sit down and do it (and return with more concrete results/questions if problem persists), or hire someone to do that (on that specific device or similar one).
-
This post is deleted!
-
@Konstantin-Tokarev said in QWebView - On Click CPU Performance:
Qt 4.8.4 is EOL, WebKit shipped with it is forked from WebKit upstream as of 2011 so it may be seriously lacking on Web platform features and cause pages to load tons of polyfills. You may want to use QtWebKit 2.3.4 with Qt 4.8.4, it's a bit newer WebKit (2012), however there is no guarantee that it will work better.
It also can be that bad performance is caused by graphic animations on your page, in this case hardware acceleration (i.e., QGLWidget viewport and enabled AcceleratedCompositing) may helpThank you @Konstantin-Tokarev This explanation means a lot. This helps us to understand that we are using older version of Qt WebKit and which is not really efficient.
At this moment of time, we don't have a plan to update to the latest version. We will have to find a work around in the application to manage the situation. -
@Konstantin-Tokarev said in QWebView - On Click CPU Performance:
Well, it indeed was hosted in official repo, and was counted as "port", not a "fork". But there are a few things to consider:
Qt port does a lot of things differently from other WebKit ports, e.g. it uses Qt for networking, graphics, has lots of other custom code paths
Stable versions (both those released as a part of Qt and standalone) are technically forks, since they are based on branch starting in upstream WebKit and containing modifications on top of that
Right now few people in WebKit community around webkit.org are aware of Qt port and its peculiarities; I'm probably the only oneAlso, question in this topic is of a kind "go profile & debug it on device" - so, instead of asking on forums, author should either sit down and do it (and return with more concrete results/questions if problem persists), or hire someone to do that (on that specific device or similar one).
@Konstantin-Tokarev Yes, we have been trying to understand who consumes the lot of CPU and why. When I did profiling using gprof/perf tools, I can find out that which function in my application consumes a lot, but that does not root in to the framework, which is webkit. Do you recommend any method which I can profile the framework side as well?
And even if we find issues in the framework, at this moment we are not in a position to upgrade the system. So we will identify the work around and live with it ( Already found couple of work around solution, which I will be sharing it in a while here )Reason for asking such question is,
Someone might have faced similar problem and might have the ready solution. Instead of I spending lot of time in exploring, researching, debugging, etc, I could post it here to know if someone knows about it. However, in parallel to posting this question, I have been doing things in parallel if in case I don't get the answer. For this post, you being a legend on webkit, you have mentioned that it could be a problem of webkit version that we use, which makes sense and unveils the root cause.As mentioned above, I will share some of the work around fixes that would fix the UI 'freeze' issue.
Thank you!
-
@kumararajas said in QWebView - On Click CPU Performance:
Thank you @Konstantin-Tokarev This explanation means a lot. This helps us to understand that we are using older version of Qt WebKit and which is not really efficient.
At this moment of time, we don't have a plan to update to the latest version. We will have to find a work around in the application to manage the situation.Does it mean that you cannot change any bits of software in your system and you are limited to workarounds on the side of web page? If so, it's really sad situation.
If you are able to change software, you are strongly adviced to use QtWebKit 2.3.4, or at least give it a try.
@kumararajas said in QWebView - On Click CPU Performance:
@Konstantin-Tokarev Yes, we have been trying to understand who consumes the lot of CPU and why. When I did profiling using gprof/perf tools, I can find out that which function in my application consumes a lot, but that does not root in to the framework, which is webkit. Do you recommend any method which I can profile the framework side as well?
Don't use
gprof. This tool claims to measure time spent in functions, but in fact measures totally different thing. And, as you've already discovered, it can only profile code which was rebuilt with-pgflag.As for
perf, it is decent tool. On older systemsoprofilecan be used. Make sure that your QtWebKit library is not strippedAnd even if we find issues in the framework, at this moment we are not in a position to upgrade the system. So we will identify the work around and live with it ( Already found couple of work around solution, which I will be sharing it in a while here )
I have no idea what do you mean here, and I don't really want to be in your shoes. (/me once had to reverse engineer and then binary patch 3rd party kernel driver with no source code, but at least there were no problems with updating target system)
Reason for asking such question is,
Someone might have faced similar problem and might have the ready solution. Instead of I spending lot of time in exploring, researching, debugging, etc, I could post it here to know if someone knows about it. However, in parallel to posting this question, I have been doing things in parallel if in case I don't get the answer. For this post, you being a legend on webkit, you have mentioned that it could be a problem of webkit version that we use, which makes sense and unveils the root cause.I'm far from being legend, and there may be other reasons of high CPU consumptions, maybe several factors at once. It can be that WebKit just doesn't have enough memory to process page, and system is thrashing (you'll see high
sysusage intopthen).When I touch the report, does Qt Web Kit renders the whole web page again?
If you are not using
QWebSettings::TiledBackingStoreEnabledand are not using accelerated composting onQGLWidgetviewport, and are not usingQWebPage::setPreferredContentsSize, then QtWebKit definitely reners whole page again after scroll. It doesn't redraw old pixel, but it performs whole rendering procedure with QPainter being clipped to update region. It may easily be a bottleneck if page is complex
