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

Posted 2023-03-07

【中文标题】处理草图没有流畅的动画，但 GPU/CPU 负载和帧率正常

【英文标题】：No smooth animation for processing sketch, yet normal GPU/CPU load and framerate

【发布时间】：2014-01-05 21:12:20

【问题描述】：

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

我正在做的是通过 oscP5 接收相对坐标（x 和 y 轴上的 0.-1.）。这通过一个数据处理程序来检查该区域是否在 x 时间内没有输入。如果一切正常，则会创建一个新的 Wave 对象，该对象将在其位置上绘制一个扩展（调制）圆。由于安装必须非常灵活，所有视觉参数都可以通过 controlP5 GUI 进行调整。

所有这一切都在具有 i7 3770 3.4Ghz、8 GB RAM 和两个 Radeon HD7700 的计算机上运行，​​以通过 VGA（只需绘制一个 3072x1536 的窗口）。 CPU 和 GPU 负载是合理的 (http://imgur.com/a/usNVC)，但性能不是我们想要的。

我们尝试了多种解决方案，包括：更改渲染模式；尝试不同的 GPU；不同的绘图方法；改变进程优先级；导出到应用程序；等等，但似乎没有什么明显的改善。所以现在我猜它要么只是处理/java无法在多​​个监视器上顺利运行，要么是我的代码中导致了这种情况......

我如何在 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();

我希望我已经提供了足够的信息来掌握问题所在！

【参考方案1】：

我和我的同事在使用 Eyefinity 设置从一台 PC 运行 PowerWall（6x3 显示器）时遇到了类似的问题。简短的版本是，正如您所发现的，在多张卡片上运行处理草图存在很多问题。

我们倾向于使用不同的方法来解决这个问题 - 应用程序的多个副本，每个副本仅跨越一个监视器，呈现一个子部分并同步它们自己。这是人们在从多台机器上驱动大型显示器时倾向于使用的方法，但它似乎也回避了这些帧率问题。

对于 Processing，有几个库支持这一点：Dan Shiffman 的 Most Pixels Ever 和德克萨斯高级计算中心的 Massive Pixel Environment。他们都有合理的示例，可以帮助您完成设置阶段。

但有一个附带条件，如果我们尝试使用 OpenGL 渲染进行此操作，我们会不断遇到来自 JOGL 的崩溃 - 这是大约 6 个月前的情况，所以现在可能已经修复了。您的绘制循环看起来使用 Java2D 会没问题，所以希望这对您来说不是问题。

【讨论】：

感谢您分享您的经验。这证实了我的怀疑，即我们的问题不是我们可以通过简单地优化代码来解决的。目前的行动计划是，我们将首先尝试制作一个 OpenFrameworks(C++) 端口（学习该语言也很有趣），如果它仍然给我们带来继续 MPE 的问题。

你到底有没有得到这个结果？ OpenFrameworks 更适合吗？

回复很晚，但最终我们选择了使用 Vioso 系统。这也使我们能够将所有投影图像混合在一起。