Rmagick、GraphicsMagick 在服务器上似乎超级慢(为什么在本地上还可以)

发布于 2024-12-18 08:05:17 字数 3205 浏览 4 评论 0原文

我正在寻找一种非常快速的方法来从放置在某些背景上的小图块渲染动态图像(想象一下动态渲染国际象棋游戏并在每个玩家采取行动后发送图像)。 所以这个过程看起来很简单: 1.了解一些背景 2. 使用图像偏移从上到下放置国际象棋棋子的透明图像(以获得正确的视角) 3.将整个图片保存为gif

尝试使用imagemagick:

使用类似的东西:

convert -page 176x220 -gravity SouthWest 1.png   -page +35+30 -gravity SouthWest 1.png     -page +62+50       1.png   -page +10+55 1.png -background none  -compose DstOver  -flatten      result.gif

和graphics magick以类似的方式: gm Convert ... -page+35+-30 -flatten ..

但没有留下深刻的印象,GraphicsMagick 提供了更好的结果,但是:

服务器:

             user     system      total        real
all:     0.000000   0.000000  47.650000 ( 70.991829)
small:   0.000000   0.000000   6.600000 (  8.110900)
medium:  0.000000   0.000000   6.820000 (  8.494131)
large:   0.000000   0.000000  10.890000 ( 15.818351)
extreme:  0.000000   0.000000  11.160000 ( 19.873541)
biggest:  0.000000   0.000000  11.640000 ( 14.327450)

在本地 Phenom II x6 上:

             user     system      total        real
all:     0.000000   0.000000   1.980000 (  0.757320)
small:   0.000000   0.000000   0.330000 (  0.082142)
medium:  0.000000   0.000000   0.380000 (  0.127744)
large:   0.000000   0.000000   0.410000 (  0.147252)
extreme:  0.000000   0.000000   0.440000 (  0.180338)
biggest:  0.000000   0.000000   0.470000 (  0.210802)

认为文件加载可能是问题,尝试了 Rmagick(脚本来自: http://www.imagemagick.org/RMagick/doc/ilist.html#mosaic ):

    require "benchmark"
    require 'RMagick'

    #Demonstrate the mosaic method

    a = Magick::ImageList.new

    26.times do
      a.read("csii/some_asset.miff")
    end


    b = Magick::ImageList.new
    page = Magick::Rectangle.new(0,0,0,0)
    a.scene = 0
    2.times do |i|
        2.times do |j|
            b << a.scale(1)
            page.x = j * b.columns
            page.y = i * b.rows
            b.page = page
            (a.scene += 1) rescue a.scene = 0
        end
    end

    # Make a 5x5 mosaic
    #mosaic = b.flatten_images
    #mosaic.write("mosaic.gif")

    # mosaic.display
    Benchmark.bm(7) do |ben|
      ben.report("tiny:")   {mosaic = b.mosaic}
    end

    exit

结果更奇怪: 这是一个微小的 2*2 瓷砖图像

服务器:

         user     system      total        real
tiny:   16.210000   0.000000  16.210000 ( 16.982007)

PHENOM:

             user     system      total        real
tiny:    0.000000   0.010000   0.010000 (  0.001637)

附加信息:

输入文件格式:尝试过 png 和 miff

输出:必须是 gif

服务器:1 个 XEON 核心VPS ~2.2Ghz

PHENOM:6* 3.2Ghz

版本差异:

Phenom
Version: ImageMagick 6.5.7-8 2010-12-02 Q16 http://www.imagemagick.org

Server 
Version: ImageMagick 6.5.1-0 2010-12-02 Q16 OpenMP http://www.imagemagick.org

问题

  1. 对速度降低高达10000倍?
  2. 关于如何以任何其他方式(其他 GM 或 IM 功能?)或方法(现在尝试 chunky_PNG(使用oily_png ext.)完成此任务的任何想法?
  3. DOS 时代的旧 2d 游戏可以以 60fps 渲染更多像素,所以我想它应该能够在 2Ghz CPU 上完成这个任务(我猜 200ms 就可以了)?

I am looking for a very quick way to render dynamic images from small tiles placed on some background (imagine dynamically rendering a chess game and sending images after each player makes a move).
So the procedure seems to be quite simple:
1. Take some background
2. Put transparent images of chess figures from top to bottom using image offsets (to have correct perspective)
3. Save the whole picture as gif

Tried using imagemagick:

using something similar to:

convert -page 176x220 -gravity SouthWest 1.png   -page +35+30 -gravity SouthWest 1.png     -page +62+50       1.png   -page +10+55 1.png -background none  -compose DstOver  -flatten      result.gif

And graphics magick in similar way:
gm convert ... -page+35+-30 -flatten..

But was not impressed, GraphicsMagick provided better results but:

SERVER:

             user     system      total        real
all:     0.000000   0.000000  47.650000 ( 70.991829)
small:   0.000000   0.000000   6.600000 (  8.110900)
medium:  0.000000   0.000000   6.820000 (  8.494131)
large:   0.000000   0.000000  10.890000 ( 15.818351)
extreme:  0.000000   0.000000  11.160000 ( 19.873541)
biggest:  0.000000   0.000000  11.640000 ( 14.327450)

On local Phenom II x6:

             user     system      total        real
all:     0.000000   0.000000   1.980000 (  0.757320)
small:   0.000000   0.000000   0.330000 (  0.082142)
medium:  0.000000   0.000000   0.380000 (  0.127744)
large:   0.000000   0.000000   0.410000 (  0.147252)
extreme:  0.000000   0.000000   0.440000 (  0.180338)
biggest:  0.000000   0.000000   0.470000 (  0.210802)

Thought maybe the file loading is the issue, tried Rmagick(script from: http://www.imagemagick.org/RMagick/doc/ilist.html#mosaic ):

    require "benchmark"
    require 'RMagick'

    #Demonstrate the mosaic method

    a = Magick::ImageList.new

    26.times do
      a.read("csii/some_asset.miff")
    end


    b = Magick::ImageList.new
    page = Magick::Rectangle.new(0,0,0,0)
    a.scene = 0
    2.times do |i|
        2.times do |j|
            b << a.scale(1)
            page.x = j * b.columns
            page.y = i * b.rows
            b.page = page
            (a.scene += 1) rescue a.scene = 0
        end
    end

    # Make a 5x5 mosaic
    #mosaic = b.flatten_images
    #mosaic.write("mosaic.gif")

    # mosaic.display
    Benchmark.bm(7) do |ben|
      ben.report("tiny:")   {mosaic = b.mosaic}
    end

    exit

The result is even more wierd:
THIS IS FOR A TINY 2*2 tiles image

SERVER:

         user     system      total        real
tiny:   16.210000   0.000000  16.210000 ( 16.982007)

PHENOM:

             user     system      total        real
tiny:    0.000000   0.010000   0.010000 (  0.001637)

ADDITIONAL INFO:

INPUT FILE FORMATS: tried png and miff

OUTPUT: must be gif

SERVER: 1 XEON core on VPS ~2.2Ghz

PHENOM: 6* 3.2Ghz

Version differences:

Phenom
Version: ImageMagick 6.5.7-8 2010-12-02 Q16 http://www.imagemagick.org

Server 
Version: ImageMagick 6.5.1-0 2010-12-02 Q16 OpenMP http://www.imagemagick.org

QUESTIONS

  1. Any ideas for the up to 10000 times reduction in speed?
  2. Any ideas of how I could achieve this task in any other way(other GM or IM function?) or method (Trying out chunky_PNG now (with oily_png ext.)?
  3. The old 2d games of DOS era could render even more pixels at 60fps, so I guess it should be able to accomplish this on a 2Ghz CPU (200ms would be OK I guess)?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

櫻之舞 2024-12-25 08:05:17

似乎每次我问一个关于 SO 的问题时,答案都会立即出现。

这次看来性能问题是因为 IM 和 GM 中的 OpenVz VPS 和 OpenMP。在没有 OpenMP 功能的情况下重新编译后,服务器上的性能非常好。

It seems every time I ask a question on SO, the answer comes to me immediately.

This time it seems the performance issue is because of OpenVz VPS and OpenMP in IM and GM. After recompiling without OpenMP feature, the performance is great on the server.

病女 2024-12-25 08:05:17

众所周知,RMagick 会在生产中引起各种问题(主要与内存泄漏有关)。我不知道细节,但我确实知道使用 mini_magick 可以缓解大多数性能问题。也许你应该尝试一下。

RMagick is known to cause all sorts of issues in production (mostly related to memory leaks). I don't know the details, but I do know that using mini_magick alleviates most performance problems. Maybe you should give it a shot.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文