没有流畅的动画处理草图，但正常的GPU/CPU负载和框架

Question

我正在研究交互式安装的可视化，如下所示：http://vimeo.com/78977964。但是我遇到了一些关于动画流畅性的问题。当它告诉我它运行在一个稳定的30或60 fps上时，实际的图像一点也不平滑；想象一个15 fps的动画和一个不稳定的时钟。你们能给我一些关于优化我的素描的方向的建议吗？

我所做的是接收相对坐标(0.1)。在x和y轴上)通过oscP5。这将通过数据处理程序来检查该区域是否有x段时间没有输入。如果一切正常，将创建一个新的Wave对象，该对象将在其位置上绘制一个扩展(调制)圆。由于安装必须非常灵活，所有可视参数都可以通过controlP5图形用户界面进行调整。

所有这些都运行在一台i7 3770 3.4GHz、8 GB RAm和两台Radeon 7700的计算机上，通过VGA驱动4到10台松下EX600 XGA投影仪(只需绘制3072x1536窗口)。CPU和GPU负载是合理的( http://imgur.com/a/usNVC )，但性能不是我们所希望的那样。

我们尝试了许多解决方案，包括:改变渲染模式；尝试不同的GPU；不同的绘图方法；更改进程优先级；导出到应用程序等。所以现在我猜它要么只是处理/java无法在多个监视器上顺利运行，要么是在我的代码中导致了这一点.

如何在wave类中绘制波形(这是从每个wave对象的主绘制循环中调用的)

public void draw(){

this.diameter = map(this.frequency, lowLimitFrequency, highLimitFrequency, speedLowFreq, speedHighFreq) * (millis()-date)/5f;

strokeWeight(map(this.frequency, lowLimitFrequency, highLimitFrequency, lineThicknessLowFreq, lineThicknessHighFreq)*map(this.diameter, 0, this.maxDiameter, 1., 0.1)*50);

stroke(255,255,255, constrain((int)map(this.diameter, 0, this.maxDiameter, 255, 0),0,255));

pushMatrix();
beginShape();

translate(h*this.x*width, v*this.y*height);

//this draws a circle from line segments, and is modified by a sinewave
for (int i = 0;i<segments;i++) {

  vertex(
  (this.distortion*sin(map(i, 0, segments, 0, this.periods*TWO_PI))+1)* this.diameter*sin(i*TWO_PI/segments), 
  (this.distortion*sin(map(i, 0, segments, 0, this.periods*TWO_PI))+1)* this.diameter* cos(i*TWO_PI/segments)
    );
}
vertex(
(this.distortion*sin(map(0, 0, segments, 0, this.periods*TWO_PI))+1)* this.diameter*sin(0*TWO_PI/segments), 
(this.distortion*sin(map(0, 0, segments, 0, this.periods*TWO_PI))+1)* this.diameter* cos(0*TWO_PI/segments)
  );


endShape();
popMatrix();

}

我希望我已经提供了足够的信息来了解出了什么问题！

Answer 1

我和我的同事们在这里也遇到过类似的问题，使用Eyefinity设置从一个PC上运行一个PowerWall (6x3监视器)。简短的版本是，正如您所发现的，在多张卡片上运行处理草图存在很多问题。

我们倾向于使用一种不同的方法来解决这个问题--应用程序的多个副本，每个副本只跨越一个监视器，呈现一个分段并同步起来。这是人们在从多台机器驱动大型显示器时倾向于使用的方法，但它似乎也避开了这些框架问题。

对于处理，有几个库支持这一点: Dan的史上最像像素和来自德克萨斯高级计算中心的大规模像素环境。他们都有合理的例子，应该可以帮助您通过安装阶段。

但有一个条件是，如果我们尝试使用OpenGL渲染，我们仍然会遇到来自JOGL的崩溃--这是大约6个月前的事了，所以现在可能已经解决了。您的抽签循环看起来使用Java2D是可以的，所以希望这不会成为您的问题。