Support #4890
openScrolling many WPaintedWidgets and chrome 50 performance regression
0%
Description
Hi Koen!
I don't know if this is related to our setFormObject(...) problem (Issue #4731) a month ago but:
Since Chrome "50.0.2661.94 m" we have huge performance problems with scrolling many painted widgets.
WT version did not change.
:-(
Is there a way that I can show you our problem...?
BR,
Max
Files
Updated by Max Quatember over 8 years ago
Hi Koen!
I changed our preferredMethod to "InlineSvgVml" and the scrolling is ok again.
With HtmlCanvas it is slow as hell. It seems that the browser renders more than it has to...?
Maybe this is interesting for you. I can show you the behaviour if you want me to.
At the moment we can workaroud this issue.
BR,
Max
Updated by Koen Deforche over 8 years ago
- Status changed from New to InProgress
- Assignee set to Roel Standaert
- Target version set to 3.3.6
Updated by Roel Standaert over 8 years ago
I've tried to test this with Chrome 50.0.2661.94 and Chromium 49.0.2623.23 and haven't noticed any difference.
Could you record a timeline (ctrl+shift+I, timeline tab) in both browsers, maybe? You can save the date with right click -> save timeline data.
I used Chromium Portable to test version 49: https://sourceforge.net/projects/crportable/files/?source=navbar
Updated by Max Quatember over 8 years ago
- File timelines.7z timelines.7z added
Hi Roel!
Please see the recorded timelines attached.
BR,
Max
Updated by Max Quatember over 8 years ago
- File timelines.7z timelines.7z added
Something went wrong while saving the slow timeline, here the right one attached!
Max
Updated by Roel Standaert over 8 years ago
That's strange. The slow timeline seems mostly idle. Could you also check the "Paint" checkbox when capturing?
Updated by Max Quatember over 8 years ago
- File timeline_chromium_48.7z timeline_chromium_48.7z added
- File timeline_chromium_51.7z timeline_chromium_51.7z added
Here the timelines with "paint" checked.
Updated by Roel Standaert over 8 years ago
On what operating system are you testing? I'm looking to see if any Chrome issue was reported.
Updated by Roel Standaert over 8 years ago
I reported this to the Chromium developers: https://bugs.chromium.org/p/chromium/issues/detail?id=612824.
However, I have not been able to reproduce this problem myself. Could you maybe provide an HTML file that reproduces the issue if possible?
Updated by Roel Standaert over 8 years ago
- Status changed from InProgress to Feedback
Updated by Max Quatember over 8 years ago
Hi Roel!
Thanks for the help.
It is not possible for me to extract this part of our application and convert it in a standalone html file...
What I can offer is, that I can show this behaviour in a live session (teamviewer, rdp,...) to a chrome developer.
Is there a way to contact one?
Best regards
Max
Updated by Roel Standaert over 8 years ago
I think you can maybe get in touch with them through this issue: https://bugs.chromium.org/p/chromium/issues/detail?id=612824
Updated by Max Quatember over 8 years ago
Hi!
For me it's ok to close this issue, because the discussion moved to bugs.chromium.org...
BR,
Max
Updated by Max Quatember over 8 years ago
Hi!
After providing some debug information I got an answer from a chromium developer.
https://bugs.chromium.org/p/chromium/issues/detail?id=612824#c11
What does "Removing the scrolling component" in our case mean?
Is this something I can manipulate or is this a Wt-issue?
BR,
Max
Updated by Roel Standaert over 8 years ago
He was just referring to the issue. It was marked as related to "Blink>Compositing" and "Blink>Scrolling" before, but it's now been unmarked as related to the Scrolling component. He's just established that it's a compositing issue in Chrome.
There's nothing we or you can do I think.
Regards,
Roel