为什么会这样摇晃? [英] Why does this wobble?

问题描述

在处理 2.2.1 & 上测试3.0a2 在 OS X 上.

Tested on Processing 2.2.1 & 3.0a2 on OS X.

我在下面调整的代码对你们中的一些人来说可能看起来很熟悉，这就是 Imgur 现在用作加载动画的代码.它发布在 OpenProcessing.org 上，我已经能够让它在 Processing 中工作，但是弧线不断地摆动(相对运动在 1 像素内).我是 Processing 的新手，我在草图中没有看到任何可能导致这种情况的内容，它在 ProcessingJS 中运行没有问题(尽管 CPU 利用率非常高).

The code I've tweaked below may look familiar to some of you, it's what Imgur now uses as their loading animation. It was posted on OpenProcessing.org and I've been able to get it working in Processing, but the arcs are constantly wobbling around (relative movement within 1 pixel). I'm new to Processing and I don't see anything in the sketch that could be causing this, it runs in ProcessingJS without issue (though very high CPU utilization).

int num = 6;

float step, spacing, theta, angle, startPosition;

void setup() {
  frameRate( 60 );
  size( 60, 60 );
  strokeWeight( 3 );
  noFill();
  stroke( 51, 51, 51 );
  step = 11;
  startPosition = -( PI / 2 );
}

void draw() {
  background( 255, 255, 255, 0 );
  translate( width / 2, height / 2 );
  for ( int i = 0; i < num; i++ ) {
    spacing = i * step;
    angle = ( theta + ( ( PI / 4 / num ) * i ) ) % PI;
    float arcEnd = map( sin( angle ), -1, 1, -TWO_PI, TWO_PI );
    if ( angle <= ( PI / 2 )  ) {
      arc( 0, 0, spacing, spacing, 0 + startPosition , arcEnd + startPosition  );
    }
    else {
      arc( 0, 0, spacing, spacing, TWO_PI - arcEnd + startPosition , TWO_PI + startPosition  );
    }
  }
  arc( 0, 0, 1, 1, 0, TWO_PI );
  theta += .02;
}

如果有帮助，我正在尝试将其导出为动画 GIF.我尝试用 ProcessingJS 和 jsgif 来做这件事，但遇到了一些障碍.我可以使用 gifAnimation 将它导出到 Processing 中.

If it helps, I'm trying to export this to an animated GIF. I tried doing this with ProcessingJS and jsgif, but hit some snags. I'm able to get it exported in Processing using gifAnimation just fine.

更新

看起来我要使用 hint( ENABLE_STROKE_PURE );，在 setup() 中使用 strokeCap( SQUARE ); 清理.它看起来和原来的不一样，但我喜欢直边.有时，当您妥协时，结果甚至比理想"解决方案还要好.

Looks like I'm going with hint( ENABLE_STROKE_PURE );, cleaned up with strokeCap( SQUARE ); within setup(). It doesn't look the same as the original but I do like the straight edges. Sometimes when you compromise, the result ends up even better than the "ideal" solution.

推荐答案

我在 OS X 2.2.1 上看到了这个问题，并在 setup()hint(ENABLE_STROKE_PURE) 中调用了hint(ENABLE_STROKE_PURE)/code> 为我修复了它.不过，我找不到有关此调用的良好文档；它只是在这里和那里被提及.

I see the problem on 2.2.1 for OS X, and calling hint(ENABLE_STROKE_PURE) in setup() fixes it for me. I couldn't find good documentation for this call, though; it's just something that gets mentioned here and there.

至于根本原因，如果我绝对必须推测的话，我猜想 Processing 的 Java 渲染器使用带有少量控制点的样条来近似圆弧.控制点在端点之间间隔开，因此随着端点移动，近似中的颠簸也会移动.对于单帧来说，近似值可能足够好，但动画使颠簸变得明显.设置 ENABLE_STROKE_PURE 可能会增加控制点的数量，或者可能会强制 Processing 在其构建的底层图形库中使用更昂贵的圆弧图元.不过，这只是对为什么绘图环境可能有您所见过的错误的一种猜测.我还没有阅读 Processing 的源代码来验证猜测.

As for the root cause, if I absolutely had to speculate, I'd guess that Processing's Java renderer approximates a circular arc using a spline with a small number of control points. The control points are spaced out between the endpoints, so as the endpoints move, so do the bumps in the approximation. The approximation might be good enough for a single frame, but the animation makes the bumps obvious. Setting ENABLE_STROKE_PURE might increase the number of control points, or it might force Processing to use a more expensive circular arc primitive in the underlying graphics library it's built upon. Again, though, this is just a guess as to why a drawing environment might have a bug like the one you've seen. I haven't read Processing's source code to verify the guess.

这篇关于为什么会这样摇晃?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！