Issue metadata
Sign in to add a comment
|
button click handler slower than WebKit
Reported by
jba...@implen.de,
Jun 12 2017
|
||||||||||||||||||||||
Issue description
UserAgent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:53.0) Gecko/20100101 Firefox/53.0
Steps to reproduce the problem:
open this index.html file:
<!DOCTYPE HTML>
<!doctype html>
<html>
<body>
<head>
<meta http-equiv="X-UA-Compatible" content="IE=edge">
<meta charset="UTF-8">
<meta name="viewport" content="width=device-width, initial-scale=1, maximum-scale=1, user-scalable=no">
<title>Implen</title>
<script language="javascript" type="text/javascript">
var toggle = true;
function myFunction () {
if (toggle) {
document.getElementById("demo").innerHTML = "Hello World";
toggle = false;
} else {
document.getElementById("demo").innerHTML = "";
toggle = true;
}
}
</script>
<style>
.centered {text-align:center;}
.button {
background-color: #4CAF50;
border: none;
color: white;
padding: 15px 32px;
text-align: center;
text-decoration: none;
display: inline-block;
font-size: 72px;
margin: 4px 2px;
cursor: pointer;
}
.text {
font-size: 72px;
}
</style>
</head>
<body>
<div class="centered">
<button class="button" onclick="myFunction()">Click me</button>
<div class="text" id="demo"/>
</div>
</body>
</html>
What is the expected behavior?
Chromium should be at least as fast as WebKit.
What went wrong?
I ran the above HTML / JavaScript on WebKit and Chromium and recorded the behavior with a highspeed camera (1000 fps):
- WebKit: 66 ms
- Chromium: 105 ms
Did this work before? N/A
Chrome version: 57.0.2948.0 Channel: dev
OS Version: Debian Wheezy
Flash Version: n/a
,
Jun 12 2017
Regarding comment 1: With the JavaScript approach, it is measured when the following events are happening: - mousedown - mouseup - click But I am interested in the time between I actually released the button and something is visible on the screen. Therefore I used the high-speed camera. Regarding comment 2: Before I did the actual measurement, I pressed the button several times. Regarding comment 3: In both browsers, the button click is only handled when releasing the button.
,
Jun 13 2017
Issue 732376 has been merged into this issue.
,
Jun 13 2017
,
Jun 14 2017
,
Jun 19 2017
Tested this issue on Windows 10, Ubuntu 14.04 and mac 10.12.5 with chrome Stable #59.0.3071.104 and canary #61.0.3135.0 with test case provided in comment #1 Didn't observe any delay in the chrome browser. Observed that "Click" event is fired after the "Mouse Up" event is fired. Attaching the screen-cast for reference. jbauer@ could you please look into it and let us know your observations.
,
Jun 19 2017
As described in comment #2, I am observing the time between actually releasing the button and something is rendered on the screen. I think this can only be observed with a touch screen and a high-speed camera. I did the test on Embedded Linux, which runs WebKit (e.g. in Qt4) and Chromium, but a system, which has a touch screen and runs Safari as well as Chromium, should be suitable as well.
,
Jun 19 2017
Thank you for providing more feedback. Adding requester "kkaluri@chromium.org" to the cc list and removing "Needs-Feedback" label. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Jun 20 2017
Passing this issue to MTV as we don't have the above configured machine here with India team. @prudhvi: Can you please take a look at it Thanks!!
,
Jun 22 2017
I did the same test on an iPad with the most recent Chrome and Safari (see attachments). The effect is visible, but less prominent: - Safari: 97 ms - Chrome: 110 ms
,
Jul 6 2017
,
Jul 7 2017
Chrome on an iPad uses webkit underneath. So the difference you are measuring there is likely noise. For the embedded linux device: Are you able to provide a trace (chrome://tracing) from the device? Probably all categories would be best then we can see what is taking a certain amount of time.
,
Jul 7 2017
,
Jul 10 2017
I was able to do a trace from the device with all categories.
,
Jul 10 2017
Thank you for providing more feedback. Adding requester "dtapuska@chromium.org" to the cc list and removing "Needs-Feedback" label. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Jul 10 2017
The trace definitely shows that you are using the software renderer instead of the GL renderer. From the trace handling the gesture tap is about 85ms. Handling the event is roughly 45ms of that. With the remaining 40ms in the compositing, painting. Have you tried to ensure that the GL renderer is used on this hardware? Perhaps it is being used in WebKit and that ultimately is the difference.
,
Jul 10 2017
Thanks for this analysis. Yes, I am aware that I am using the software renderer. I am using X11 without GL support right now, but I am also working to get GL support in X11 working. However, Qt4 WebKit runs in the very same X11 environment, i.e. with software renderer.
,
Jul 10 2017
I don't think there is anything that is unreasonably long that requires specific actions. Different browsers have fundamentally different execution times because of different trade-offs that are made but the values you are indicating are well within the RAIL guidance. 85ms with software raster is < 100ms of the response guidance. This number will get smaller as you enable the GL path so that is your best bet for making improvements as the trace seems a summation of small items.
,
Jul 10 2017
,
Jul 21 2017
The NextAction date has arrived: 2017-07-21
,
Jul 21 2017
I am still working to get X11 with GL support running. |
|||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||
Comment 1 by woxxom@gmail.com
, Jun 12 2017947 bytes
947 bytes View Download