javascript - d3 : rotations and force directed layouts

Question

当我在我的 d3 应用程序中使用旋转 tick 函数时，整个应用程序变慢了。

例如:如果您取消注释行//var angle = 0;在下面jsfiddle它运行速度快 20 倍。

这是为什么？轮换是非常昂贵还是我做错了什么？

function tick() {
  link.attr("x1", function(d) { return d.source.x; })
      .attr("y1", function(d) { return d.source.y; })
      .attr("x2", function(d) { return d.target.x; })
      .attr("y2", function(d) { return d.target.y; });

  linktext.attr("transform", function(d) {
      var xDiff = d.source.x - d.target.x; 
      var yDiff = d.source.y - d.target.y; 
      var angle = Math.atan2(yDiff, xDiff) * (180.0 / Math.PI);
      //var angle = 0;

      return "translate(" + (d.source.x + d.target.x) / 2 + ","
      + (d.source.y + d.target.y) / 2 + ")rotate(" + angle + ")"; 
    });

  node.attr("cx", function(d) { return d.x; })
      .attr("cy", function(d) { return d.y; });
}

注意:我修改了原始的 jsfiddle 发现 here

Answer 1

为了追查问题的根源，我试着让文本的各个方面相同/不同。参见 this version of your fiddle .请注意，每个文本元素的文本和 Angular 都不同(因此不可能进行优化)但是每个元素的 Angular 是恒定的——它不会在每次刻度时改变。

结果呢？一开始有点迟钝(当图形中有很多重叠时)，但它很快就会在 30fps 以下变得流畅。

同样如此(最终帧速率略高于 30fps)，即使文本内容每次更新都发生变化，如 this version .

这与 the usual rule of optimizing animation 相矛盾，改变转换应该比改变内容更有效。

根据 Chrome 帧速率检查器，大部分时间都花在了 your original fiddle 的每次重绘上。 (在我的电脑上时钟大约为 4fps)正在被“绘画设置”步骤占用——即计算图像的每个“层”。

This blog has a quick-and-easy recap of the different steps of a repaint .引用:

The following steps render the elements in the DOM into images on your screen:

1. Trigger - Elements are loaded into the DOM, or are modified in some way

2. Recalculate Styles - Styles are applied to elements (or re-calculated)

3. Layout - Elements are laid out geometrically, according to their positions on the screen

4. Paint Setup - The DOM is split up into render layers, which will be used to fill out the pixels for each element

5. Paint - Each layer is painted into a bitmap and is uploaded to the GPU as a texture by a software rasterizer

6. Composite Layers - The layers are composited together by the GPU and drawn to a final screen image

通常，转换可以在最后的“合成”步骤中由 GPU 高效完成(现代操作系统上的现代浏览器会自动将工作转移到 GPU)。

这可能不会发生的原因有两个。首先是这种优化甚至可能不适用于 SVG(尽管我很确定最新 Chrome 的默认设置是优化 SVG 转换)。然而，即使浏览器对 SVG 转换使用了一些 GPU 优化，您的 GPU 在内存耗尽之前也只能处理有限数量的层。有将近 200 个单独转换的文本元素(以及上下分层的未转换内容)，这可能会成为瓶颈。参见 this HTML5Rocks post或 this MSDN article ，其中给出了一些会取消独立层组合的性能限制示例。

无论幕后发生了什么，最终结果都是您的 CPU 而不是 GPU 每次都在计算旋转并将文本分层在一起，这效率不高。

那么，您能做些什么呢？

我尝试通过使用矩阵变换来优化代码，而不是先计算 Angular ，然后让浏览器计算旋转 (see live version) ...但这并没有产生明显的区别。更改为简单的倾斜变换而不是旋转有一点帮助(帧速率高达 11fps)，但这只是在滞后的动画之上添加了难看的文本。

不幸的是，看起来您真的不得不以一种或另一种方式妥协。一些选项:

• 隐藏文本直到强制布局停止，然后才计算旋转。 Working example

  关键代码(Javascript):

  var vis = d3.select(".intgraph").append("svg:svg")
      .attr("width", w)
      .attr("height", h)
      .append("svg:g")
     .on("click", function(){
         if ( force.alpha() )
             force.stop();
         else
             force.resume();
     });
  
  force.on("start", function(){
          vis.classed("running", true);
       })
  .on("end", function () {
      linktext.attr("transform", function (d) {
          var xDiff = d.source.x - d.target.x,
              xMid = d.source.x - xDiff / 2;
          var yDiff = d.source.y - d.target.y,
              yMid = d.source.y - yDiff / 2;
          var hyp = Math.sqrt(xDiff * xDiff + yDiff * yDiff),
              cos = xDiff / hyp,
              sin = yDiff / hyp;
          return "matrix(" + 
              [cos, sin, -sin, cos, xMid, yMid] + ")";
      });
      vis.classed("running", false);
  });
  

  CSS:

  .running text {
      display:none;
  }
  

• 显示文本，但不旋转它(可选，将其旋转到强制布局停止时的位置，如上所述)。