Project

General

Profile

Bug #4731

Single click on scrollbar request/response is slower than in Wt-3.3.4

Added by Markus S over 6 years ago. Updated about 6 years ago.

Status:
Closed
Priority:
Normal
Target version:
Start date:
02/12/2016
Due date:
% Done:

0%

Estimated time:

Description

The source of our software did not change, yet it seems after upgrading to Wt-3.3.5 that the response to a click on a scrollbar is more than 5 times slower compared to Wt-3.3.4.

I attached a screenshot showing the behaviour in the chrome developer console and the source of the scrollbar widget.


Files

RequestTime_Wt_334_vs_Wt_335.png (585 KB) RequestTime_Wt_334_vs_Wt_335.png Example in chrome with developer console Markus S, 02/12/2016 12:44 PM
ScrollbarWidget.cpp (4.06 KB) ScrollbarWidget.cpp Markus S, 02/12/2016 12:44 PM
ScrollbarWidget.h (1.38 KB) ScrollbarWidget.h Markus S, 02/12/2016 12:44 PM
SingleClickOnScrollbarButton_Wt-334.har (7.39 KB) SingleClickOnScrollbarButton_Wt-334.har Markus S, 02/12/2016 03:06 PM
SingleClickOnScrollbarButton_Wt-335.har (830 KB) SingleClickOnScrollbarButton_Wt-335.har Markus S, 02/12/2016 03:06 PM
RequestTime_Wt_334_vs_Wt_335.png (536 KB) RequestTime_Wt_334_vs_Wt_335.png Simpler example, button changes css style Markus S, 02/12/2016 03:06 PM
#1

Updated by Koen Deforche over 6 years ago

  • Status changed from New to Feedback

Perhaps the reason is not in the scrollbarwidget itself but in some of the rerendering that is associated with it? Can you post contents of the response itself (taken also from the developer console)? Do you have the impression that the slowdown is specifically for this particular action, or is it just only noticable with this action?

#2

Updated by Markus S over 6 years ago

Koen Deforche wrote:

Perhaps the reason is not in the scrollbarwidget itself but in some of the rerendering that is associated with it? Can you post contents of the response itself (taken also from the developer console)? Do you have the impression that the slowdown is specifically for this particular action, or is it just only noticable with this action?

Thank you for your quick response.

I checked the draw call of the cells, but it is never executed on scrolling. I attached the exported requests/response(Chrome/Save as HAR with content, I hope it's enough) for both 3.3.4 and 3.3.5.

I added another screenshot of a simpler case that does no custom painting but is also slower. It is a button that changes it's CSS on click.

Possibly it is worse if drawing actually occurs, because in another example I checked updating two cells is more than 10 times slower.

#3

Updated by Max Quatember over 6 years ago

Hi Koen,

with 3.3.4 the performance seems to be ok again.

We will switch back to 3.3.4 and try to isolate a testcase, that shows the problem.

best regards

Max

#4

Updated by Koen Deforche over 6 years ago

  • Status changed from Feedback to InProgress
  • Assignee set to Roel Standaert
  • Priority changed from Urgent to Normal
  • Target version changed from 3.3.5 to 3.3.6

WPaintedWidget should defer/avoid calling setFormObject(true) to when needed only (decide it in WPaintedWidget::render())

#5

Updated by Roel Standaert over 6 years ago

  • Status changed from InProgress to Implemented @Emweb
#6

Updated by Koen Deforche about 6 years ago

  • Status changed from Implemented @Emweb to Resolved
#7

Updated by Koen Deforche about 6 years ago

  • Status changed from Resolved to Closed

Also available in: Atom PDF