QWebView - On Click CPU Performance
-
Hello all,
I am using QWebView to display the HTML reports on my embedded target ( LCD ).
When I touch the report, I see that CPU load is shooting up.
Depends on the size of the content, time that CPU load at high consumption varies.
If the content is huge, then I can see the freeze for about 20 seconds, which is really a bad thing for an embedded system.I am very interested in knowing why this is happening.
When I touch the report, does Qt Web Kit renders the whole web page again? If yes why? How can I control that?
How can I get the mouse events only for the report content area, not the scroll bar?Platform details:
AM335X
Qt 4.8.4
Qt Web KitThank you!
Kumara -
@kumararajas said in QWebView - On Click CPU Performance:
AM335X
Which one? There's a difference between the AM3351 and the AM3359.
How much RAM do you have?
When I touch the report, does Qt Web Kit renders the whole web page again? If yes why? How can I control that?
How complex are the reports? Are they just plain HTML + CSS? Or is there lots of JavaScript also?
Qt 4.8.4
That is ancient. See if Qt 4.8.7 provides any performance improvements.
See also if you can upgrade to Qt 5.
-
Which one? There's a difference between the AM3351 and the AM3359. - AM3358
How much RAM do you have? 256MB
How complex are the reports? Are they just plain HTML + CSS? Or is there lots of JavaScript also? Report is pretty simple HTML( formatted with XSL + CSS ), but it is a huge report, we display lots of licensing details ( GPL ).
Qt 4.8.4 - Yes, I agree that it is an ancient one. At this moment of program, we don't have luxury to upgrade the Qt version, need to live with it. Even if I need to make a work around fix in application, ready to go for it. -
"Huge" doesn't tell anything. For some, a gigabyte is huge, for others, 500 kilos. Also, it might look simple, but be faulty or heavy to parse anyway. Validating the file & testing how it performs elsewhere should be the first steps. (Besides, for a human reader, a single "huge" file might not produce the best experience.)
-
@kumararajas said in QWebView - On Click CPU Performance:
AM3358
Which CPU clock rate? (600 MHz -- 1 GHz)
How much RAM do you have? 256MB
- How much of that 256 MB is available before you load a report?
- How much of that 256 MB is available after you load a report?
- How much of that 256 MB is available when you touch the report and the CPU runs at max speed?
I suspect you're running out of RAM so your system is transferring data back and forth between the RAM and the swap file to process and new sections. This transfer can be quite slow and CPU intensive.
Report is pretty simple HTML( formatted with XSL + CSS ), but it is a huge report, we display lots of licensing details ( GPL ).
Does it help if you split the report into multiple pages?
-
@mvuori I understand that I did not quantify the page size, because I didn't know the exact size. Also, whatever the size is, it also depends on the size of LCD to say how big it is.
You could imagine scrollbar handle being 20 of 100. Trying to describe the size which would tell how big the webpage is. It could be somewhere close 1MB.
I fully agree with you that a single page being so big will not produce a best user experience. Later point of time, we can think about splitting into multiple pages, but now I need to fix this 'freeze' issue. -
@JKSH said in QWebView - On Click CPU Performance:
Which CPU clock rate? (600 MHz -- 1 GHz)
1GHz
@JKSH said in QWebView - On Click CPU Performance:
Does it help if you split the report into multiple pages?
Definitely this would minimize the problem. But it wouldn't solve the problem completely. Example,
When I reduce the content and test it, I can see the UI freeze for 1 or 2 seconds ( CPU hits the maximum during that time ) and gets back to normal.
But I would like to understand the reason, when I touch the report why the CPU shoots up to 95%.
If we know the root cause, then we can find the better solution.Thank you!
-
@JKSH said in QWebView - On Click CPU Performance:
How much RAM do you have? 256MB
How much of that 256 MB is available before you load a report?
How much of that 256 MB is available after you load a report?
How much of that 256 MB is available when you touch the report and the CPU runs at max speed?I suspect you're running out of RAM so your system is transferring data back and forth between the RAM and the swap file to process and new sections. This transfer can be quite slow and CPU intensive.
I will test this and get back with the results.
-
@JKSH said in QWebView - On Click CPU Performance:
How much of that 256 MB is available before you load a report?
Around 71MB
@JKSH said in QWebView - On Click CPU Performance:
How much of that 256 MB is available after you load a report?
70MB
@JKSH said in QWebView - On Click CPU Performance:
How much of that 256 MB is available when you touch the report and the CPU runs at max speed?
No change ( 70MB )
@JKSH said in QWebView - On Click CPU Performance:
I suspect you're running out of RAM so your system is transferring data back and forth between the RAM and the swap file to process and new sections. This transfer can be quite slow and CPU intensive.
I believe that we have sufficient RAM. Please let me know your thoughts.
-
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-pg
flag.As for
perf
, it is decent tool. On older systemsoprofile
can 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
sys
usage intop
then).When I touch the report, does Qt Web Kit renders the whole web page again?
If you are not using
QWebSettings::TiledBackingStoreEnabled
and are not using accelerated composting onQGLWidget
viewport, 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