Wt

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?

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.

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