New issue
Advanced search Search tips

Issue 603850 link

Starred by 1 user

Issue metadata

Status: Duplicate
Merged: issue 589525
Owner: ----
Closed: Apr 2016
Components:
EstimatedDays: ----
NextAction: ----
OS: Windows
Pri: 2
Type: Bug



Sign in to add a comment

Drag and Drop of an SVG model on canvas is laggy with usage of JointJS framework

Reported by manoj.ho...@gmail.com, Apr 15 2016

Issue description

UserAgent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/50.0.2661.75 Safari/537.36

Steps to reproduce the problem:
We are using JointJS as a framework for visualization of models on a browser canvas. The rendering is done using SVG.

We have a use case where we have to display models with many ports with long names. 
We observed that the model rendered on the browser canvas can be dragged and moved around. However, the dragging operation is very laggy on Google Chrome. It works perfectly fine on Mozilla Firefox.

Please provide a fix for this on Google Chrome?

This is observed from Google Chrome version 49 and above. This was working fine with 48.x version of Google Chrome.

Please open index.html in the test data to reproduce the issue.

What is the expected behavior?
Drag events of SVG elements(with long names of svg elements) should be smooth

What went wrong?
This behavior is observed when there are long names of svg elements. Looks like very long names leads to laggy drag operations of svg elements.

Did this work before? Yes Google Chrome version 48.x was fine

Chrome version: 50.0.2661.75  Channel: stable
OS Version: 6.1 (Windows 7, Windows Server 2008 R2)
Flash Version: Shockwave Flash 21.0 r0
 
Test_Long_Port_names.zip
163 KB Download

Comment 1 by f...@opera.com, Apr 15 2016

Mergedinto: 589525
Status: Duplicate (was: Unconfirmed)
The issue is still reproducible. Kindly check the test data(index.html)

Comment 3 by f...@opera.com, Apr 15 2016

Components: -UI Blink>SVG
I've filed  issue 603956  for following up.
Project Member

Comment 4 by bugdroid1@chromium.org, Jun 21 2016

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/44f1431b20c16d8f8da0ce8ff7bbf2adddcdd785

commit 44f1431b20c16d8f8da0ce8ff7bbf2adddcdd785
Author: fs <fs@opera.com>
Date: Tue Jun 21 11:11:21 2016

Avoid using forced layout to trigger paint invalidation for SVG containers

Currently, SVG containers in the LayoutObject hierarchy force layout of
their children if the transform changes. The main reason for this is to
trigger paint invalidation of the subtree. In some cases - changes to the
scale factor - there are other reasons to trigger layout, like computing
a new scale factor for <text> or re-layout nodes with non-scaling stroke.

Compute a "scale-factor change" in addition to the "transform change"
already computed, then use this new signal to determine if layout should
be forced for the subtree. Trigger paint invalidation using the
LayoutObject flags instead.

The downside to this is that paint invalidation will walk into "hidden"
containers which rarely require repaint (since they are not technically
visible). This will hopefully be rectified in a follow-up CL.

For the testcase from 603850, this essentially eliminates the cost of
layout (from ~350ms to ~0ms on authors machine; layout cost is related
to text metrics recalculation), bumping frame rate significantly.

BUG= 603956 , 603850 

Review-Url: https://codereview.chromium.org/1996543002
Cr-Commit-Position: refs/heads/master@{#400950}

[modify] https://crrev.com/44f1431b20c16d8f8da0ce8ff7bbf2adddcdd785/third_party/WebKit/LayoutTests/TestExpectations
[modify] https://crrev.com/44f1431b20c16d8f8da0ce8ff7bbf2adddcdd785/third_party/WebKit/Source/core/layout/svg/LayoutSVGContainer.cpp
[modify] https://crrev.com/44f1431b20c16d8f8da0ce8ff7bbf2adddcdd785/third_party/WebKit/Source/core/layout/svg/LayoutSVGContainer.h
[modify] https://crrev.com/44f1431b20c16d8f8da0ce8ff7bbf2adddcdd785/third_party/WebKit/Source/core/layout/svg/LayoutSVGResourceMarker.cpp
[modify] https://crrev.com/44f1431b20c16d8f8da0ce8ff7bbf2adddcdd785/third_party/WebKit/Source/core/layout/svg/LayoutSVGResourceMarker.h
[modify] https://crrev.com/44f1431b20c16d8f8da0ce8ff7bbf2adddcdd785/third_party/WebKit/Source/core/layout/svg/LayoutSVGTransformableContainer.cpp
[modify] https://crrev.com/44f1431b20c16d8f8da0ce8ff7bbf2adddcdd785/third_party/WebKit/Source/core/layout/svg/LayoutSVGTransformableContainer.h
[modify] https://crrev.com/44f1431b20c16d8f8da0ce8ff7bbf2adddcdd785/third_party/WebKit/Source/core/layout/svg/LayoutSVGViewportContainer.cpp
[modify] https://crrev.com/44f1431b20c16d8f8da0ce8ff7bbf2adddcdd785/third_party/WebKit/Source/core/layout/svg/LayoutSVGViewportContainer.h
[modify] https://crrev.com/44f1431b20c16d8f8da0ce8ff7bbf2adddcdd785/third_party/WebKit/Source/core/layout/svg/SVGLayoutSupport.cpp
[modify] https://crrev.com/44f1431b20c16d8f8da0ce8ff7bbf2adddcdd785/third_party/WebKit/Source/platform/transforms/AffineTransform.cpp
[modify] https://crrev.com/44f1431b20c16d8f8da0ce8ff7bbf2adddcdd785/third_party/WebKit/Source/platform/transforms/AffineTransform.h

Sign in to add a comment