Drawing performance

[magick]

Q8 can be upwards of 100% faster than Q16 and of course Q8 uses 1/2 as much memory as Q16.

Other than using ImageMagick Q8, another performance boast comes from using an API rather than the command-line. You can eliminate the process initialization overhead with an API (PerlMagick, iMagick, MagickCore, Magick++, etc.).

[msasha]

A version I compiled from the latest sources is actually slower. Here's the configuration:

Code: Select all

ImageMagick is configured as follows. Please verify that this configuration
matches your expectations.

Host system type: x86_64-unknown-linux-gnu
Build system type: x86_64-unknown-linux-gnu

                  Option                        Value
-------------------------------------------------------------------------------
Shared libraries  --enable-shared=yes           yes
Static libraries  --enable-static=yes           yes
Module support    --with-modules=no             no
GNU ld            --with-gnu-ld=yes             yes
Quantum depth     --with-quantum-depth=16       16
High Dynamic Range Imagery
                  --enable-hdri=no              no

Delegate Configuration:
BZLIB             --with-bzlib=yes              yes
Autotrace         --with-autotrace=no           no
Dejavu fonts      --with-dejavu-font-dir=default        none
DJVU              --with-djvu=yes               yes
DPS               --with-dps=yes                no
FFTW              --with-fftw=yes               no
FlashPIX          --with-fpx=yes                no
FontConfig        --with-fontconfig=yes         yes
FreeType          --with-freetype=yes           yes
GhostPCL          None                          pcl6 (unknown)
GhostXPS          None                          gxps (unknown)
Ghostscript       None                          gs (8.70)
Ghostscript fonts --with-gs-font-dir=default    /usr/share/fonts/type1/gsfonts/
Ghostscript lib   --with-gslib=no               no
Graphviz          --with-gvc=yes                yes
JBIG              --with-jbig=yes               no
JPEG v1           --with-jpeg=yes               yes
JPEG-2000         --with-jp2=yes                yes
LCMS              --with-lcms=yes               yes
LQR               --with-lqr=yes                yes
Magick++          --with-magick-plus-plus=no    no
OpenEXR           --with-openexr=yes            yes
PERL              --with-perl=no                no
PNG               --with-png=yes                yes
RSVG              --with-rsvg=yes               yes
TIFF              --with-tiff=yes               yes
Windows fonts     --with-windows-font-dir=      none
WMF               --with-wmf=no         no
X11               --with-x=                     yes
XML               --with-xml=yes                yes
ZLIB              --with-zlib=yes               yes

X11 Configuration:
      X_CFLAGS        = 
      X_PRE_LIBS      = -lSM -lICE
      X_LIBS          = 
      X_EXTRA_LIBS    = 

Options used to compile and link:
  PREFIX          = /home/sasha/www/jinchess.com/test_chessboard/im
  EXEC-PREFIX     = /home/sasha/www/jinchess.com/test_chessboard/im
  VERSION         = 6.6.0
  CC              = gcc -std=gnu99 -std=gnu99
  CFLAGS          = -pthread -I/usr/include/OpenEXR -I/usr/include/lqr-1 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -fopenmp -g -O2 -Wall -W -pthread
  CPPFLAGS        = -I/home/sasha/www/jinchess.com/test_chessboard/im/include/ImageMagick
  PCFLAGS         = -fopenmp
  DEFS            = -DHAVE_CONFIG_H
  LDFLAGS         = 
  MAGICK_LDFLAGS  = -L/home/sasha/www/jinchess.com/test_chessboard/im/lib 
  LIBS            = -lMagickCore -llcms -ltiff -lfreetype -ljasper -ljpeg -llqr-1 -lglib-2.0 -lpng -ldjvulibre -lfontconfig -lXext -lXt -lSM -lICE -lX11 -lbz2 -pthread -lIlmImf -lz -lImath -lHalf -lIex -lIlmThread -lrsvg-2 -lgdk_pixbuf-2.0 -lm -lcairo -lgobject-2.0 -lgmodule-2.0 -lglib-2.0 -lxml2 -lgvc -lgraph -lcdt -lz -lm -lgomp -lpthread -lltdl
  CXX             = g++
  CXXFLAGS        = -g -O2 -Wall -W -pthread

I'm going to try without OpenMP and with quantum depth 8 to see if that helps any.

[msasha]

Neither of those options changed anything. The latest version is consistently about 20ms slower.

[magick]

What is the latest command sequence that you are using? We'll do some profiling on your command line and look for opportunities to speed up the process.

[msasha]

It actually hasn't changed, since I wasn't able to get any improvements from the things I tried. Here's a typical one:

Code: Select all

convert -size 320x320 xc:none -fill 'rgb(255,204,153)' -draw 'rectangle 0,0,39,39 rectangle 0,80,39,119 rectangle 0,160,39,199 rectangle 0,240,39,279 rectangle 40,40,79,79 rectangle 40,120,79,159 rectangle 40,200,79,239 rectangle 40,280,79,319 rectangle 80,0,119,39 rectangle 80,80,119,119 rectangle 80,160,119,199 rectangle 80,240,119,279 rectangle 120,40,159,79 rectangle 120,120,159,159 rectangle 120,200,159,239 rectangle 120,280,159,319 rectangle 160,0,199,39 rectangle 160,80,199,119 rectangle 160,160,199,199 rectangle 160,240,199,279 rectangle 200,40,239,79 rectangle 200,120,239,159 rectangle 200,200,239,239 rectangle 200,280,239,319 rectangle 240,0,279,39 rectangle 240,80,279,119 rectangle 240,160,279,199 rectangle 240,240,279,279 rectangle 280,40,319,79 rectangle 280,120,319,159 rectangle 280,200,319,239 rectangle 280,280,319,319 ' -fill 'rgb(143,96,79)' -draw 'rectangle 0,40,39,79 rectangle 0,120,39,159 rectangle 0,200,39,239 rectangle 0,280,39,319 rectangle 40,0,79,39 rectangle 40,80,79,119 rectangle 40,160,79,199 rectangle 40,240,79,279 rectangle 80,40,119,79 rectangle 80,120,119,159 rectangle 80,200,119,239 rectangle 80,280,119,319 rectangle 120,0,159,39 rectangle 120,80,159,119 rectangle 120,160,159,199 rectangle 120,240,159,279 rectangle 160,40,199,79 rectangle 160,120,199,159 rectangle 160,200,199,239 rectangle 160,280,199,319 rectangle 200,0,239,39 rectangle 200,80,239,119 rectangle 200,160,239,199 rectangle 200,240,239,279 rectangle 240,40,279,79 rectangle 240,120,279,159 rectangle 240,200,279,239 rectangle 240,280,279,319 rectangle 280,0,319,39 rectangle 280,80,319,119 rectangle 280,160,319,199 rectangle 280,240,319,279 ' -draw 'image Over 0,0 0,0 pieces/alpha/40/br.png' -draw 'image Over 40,0 0,0 pieces/alpha/40/bn.png' -draw 'image Over 80,0 0,0 pieces/alpha/40/bb.png' -draw 'image Over 120,0 0,0 pieces/alpha/40/bq.png' -draw 'image Over 160,0 0,0 pieces/alpha/40/bk.png' -draw 'image Over 200,0 0,0 pieces/alpha/40/bb.png' -draw 'image Over 240,0 0,0 pieces/alpha/40/bn.png' -draw 'image Over 280,0 0,0 pieces/alpha/40/br.png' -draw 'image Over 0,40 0,0 pieces/alpha/40/bp.png' -draw 'image Over 40,40 0,0 pieces/alpha/40/bp.png' -draw 'image Over 80,40 0,0 pieces/alpha/40/bp.png' -draw 'image Over 120,40 0,0 pieces/alpha/40/bp.png' -draw 'image Over 160,40 0,0 pieces/alpha/40/bp.png' -draw 'image Over 200,40 0,0 pieces/alpha/40/bp.png' -draw 'image Over 240,40 0,0 pieces/alpha/40/bp.png' -draw 'image Over 280,40 0,0 pieces/alpha/40/bp.png' -draw 'image Over 0,240 0,0 pieces/alpha/40/wp.png' -draw 'image Over 40,240 0,0 pieces/alpha/40/wp.png' -draw 'image Over 80,240 0,0 pieces/alpha/40/wp.png' -draw 'image Over 120,240 0,0 pieces/alpha/40/wp.png' -draw 'image Over 160,240 0,0 pieces/alpha/40/wp.png' -draw 'image Over 200,240 0,0 pieces/alpha/40/wp.png' -draw 'image Over 240,240 0,0 pieces/alpha/40/wp.png' -draw 'image Over 280,240 0,0 pieces/alpha/40/wp.png' -draw 'image Over 0,280 0,0 pieces/alpha/40/wr.png' -draw 'image Over 40,280 0,0 pieces/alpha/40/wn.png' -draw 'image Over 80,280 0,0 pieces/alpha/40/wb.png' -draw 'image Over 120,280 0,0 pieces/alpha/40/wq.png' -draw 'image Over 160,280 0,0 pieces/alpha/40/wk.png' -draw 'image Over 200,280 0,0 pieces/alpha/40/wb.png' -draw 'image Over 240,280 0,0 pieces/alpha/40/wn.png' -draw 'image Over 280,280 0,0 pieces/alpha/40/wr.png'   -fill 'rgba(0,175,200,128)' -strokewidth 1 -stroke 'black' -draw 'path "M182.5,260 L182.5,197.5 L189.238795325,201.326834324 L180,187.5L170.761204675,201.326834324 L177.5,197.5 L177.5,260 Z"'      -quality 80 -depth 8 -comment "Created by Alexander Maryanovsky's chess diagram generator" +matte +dither -colors 128 png:'cache/357c223989d96e64ec7f05f8835556bd'

If you need the piece images, you can find them at http://www.jinchess.com/chessboard/pieces/alpha/40/

[magick]

Thanks. We'll profile the code and see if there is a bottleneck, perhaps this weekend.

[el_supremo]

I meddled with the command and the first thing I did was to create a separate tile which in the next command was used to tile the board.
If this can be done, it saves about 43ms on my system which is Win XP Pro with a single 3.2GHz cpu with IM 6.5.9-10 Q8.
I found that I made the greatest gain when all the images were converted to GIF format. When this is done it saves 66ms compared to the original version. Looks like the PNG coder/decoder adds more overhead than GIF.

Pete

Code: Select all

# Create the basic pattern - this only needs to be done once for any given pair of light and dark colours
convert -size 80x80 xc:'rgb(143,96,79)' -fill 'rgb(255,204,153)' -draw 'rectangle 0,0,39,39 rectangle 40,40,79,79' pattern.gif

# Create the chess board using GIF format throughout
convert -size 320x320 tile:pattern.gif -draw 'image Over 0,0 0,0 pieces/alpha/40/br.gif' -draw 'image Over 40,0 0,0 pieces/alpha/40/bn.gif' -draw 'image Over 80,0 0,0 pieces/alpha/40/bb.gif' -draw 'image Over 120,0 0,0 pieces/alpha/40/bq.gif' -draw 'image Over 160,0 0,0 pieces/alpha/40/bk.gif' -draw 'image Over 200,0 0,0 pieces/alpha/40/bb.gif' -draw 'image Over 240,0 0,0 pieces/alpha/40/bn.gif' -draw 'image Over 280,0 0,0 pieces/alpha/40/br.gif' -draw 'image Over 0,40 0,0 pieces/alpha/40/bp.gif' -draw 'image Over 40,40 0,0 pieces/alpha/40/bp.gif' -draw 'image Over 80,40 0,0 pieces/alpha/40/bp.gif' -draw 'image Over 120,40 0,0 pieces/alpha/40/bp.gif' -draw 'image Over 160,40 0,0 pieces/alpha/40/bp.gif' -draw 'image Over 200,40 0,0 pieces/alpha/40/bp.gif' -draw 'image Over 240,40 0,0 pieces/alpha/40/bp.gif' -draw 'image Over 280,40 0,0 pieces/alpha/40/bp.gif' -draw 'image Over 0,240 0,0 pieces/alpha/40/wp.gif' -draw 'image Over 40,240 0,0 pieces/alpha/40/wp.gif' -draw 'image Over 80,240 0,0 pieces/alpha/40/wp.gif' -draw 'image Over 120,240 0,0 pieces/alpha/40/wp.gif' -draw 'image Over 160,240 0,0 pieces/alpha/40/wp.gif' -draw 'image Over 200,240 0,0 pieces/alpha/40/wp.gif' -draw 'image Over 240,240 0,0 pieces/alpha/40/wp.gif' -draw 'image Over 280,240 0,0 pieces/alpha/40/wp.gif' -draw 'image Over 0,280 0,0 pieces/alpha/40/wr.gif' -draw 'image Over 40,280 0,0 pieces/alpha/40/wn.gif' -draw 'image Over 80,280 0,0 pieces/alpha/40/wb.gif' -draw 'image Over 120,280 0,0 pieces/alpha/40/wq.gif' -draw 'image Over 160,280 0,0 pieces/alpha/40/wk.gif' -draw 'image Over 200,280 0,0 pieces/alpha/40/wb.gif' -draw 'image Over 240,280 0,0 pieces/alpha/40/wn.gif' -draw 'image Over 280,280 0,0 pieces/alpha/40/wr.gif' -fill 'rgba(0,175,200,128)' -strokewidth 1 -stroke black -draw 'path "M182.5,260 L182.5,197.5 L189.238795325,201.326834324 L180,187.5L170.761204675,201.326834324 L177.5,197.5 L177.5,260 Z" ' -quality 80 -depth 8 -comment 'Created by Alexander Maryanovsky's chess diagram generator' +matte +dither -colors 128 gif:'cache/e4cadb04f82f4e0ad120a004f5c6636a'

Hope I haven't introduced any syntax errors - I had to convert this back from Windows syntax.

[msasha]

For the board, as I mentioned earlier, I can't use the tile: operator to create the image, because the board does not always cover the entire image. See http://www.jinchess.com/chessboard/?p=r ... QKBNR&cm=o for example.

For the pieces, I can't store them as GIFs, because that only has a binary alpha channel, and my pieces are antialiased on a transparent background. I could pre-render each piece on both dark and light squares, but that would only help in some of the cases, as the square colors are user-specified.

[fmw42]

what about using png or tif with 8-bit alpha for the pieces? or is it too slow to load such file? also memory mapped mpc format supports 8-bit alpha and those can be created once and used from command line to command line for each move of the pieces and you can use clones for each copy of that piece. again, not sure if loading these would still be too slow vs drawing from scratch each time.

[msasha]

what about using png or tif with 8-bit alpha for the pieces? or is it too slow to load such file?

I'm not sure what you mean - I'm already using PNGs with 8-bit alpha for my piece images. Is there a reason to believe TIFF would be faster? I'll try it I guess...

also memory mapped mpc format supports 8-bit alpha and those can be created once and used from command line to command line for each move of the pieces and you can use clones for each copy of that piece. again, not sure if loading these would still be too slow vs drawing from scratch each time.

I've already tried preloading all the piece images from PNG to mpr and then drawing the mpr images onto the board, and that wasn't any faster than drawing the pieces directly from PNG. I don't see mpc being faster than that, because the images are small and the entire image is needed anyway (so there's no advantage in memory-mapping).

Most of the time seems to be spent in drawing the images, not in loading them.

[fmw42]

I've already tried preloading all the piece images from PNG to mpr and then drawing the mpr images onto the board, and that wasn't any faster than drawing the pieces directly from PNG. I don't see mpc being faster than that, because the images are small and the entire image is needed anyway (so there's no advantage in memory-mapping).

The advantage is not for one move, but in using the stored mpc retrieved over and over for each move (along with clones so you don't have to load the same piece image over and over such as for pawns). The mpc can be stored as a temporary file and used throughout a script (that I assume you use to go from move to move). If you have to run the same commands for each move and cannot use a single script for the whole game, then you lose the advantage of the mpc when loading your images. But you should be able to use clones for each copy of any one piece rather than loading it from disk each time.


With regard to tiff, I was hoping there would be either an 8-bit color with 8-bit alpha version or atleast you can use a compressed 24-bit tiff with 8-bit alpha. But I am not an expert on either tiff or png. But see

http://www.imagemagick.org/Usage/formats/#png
http://www.imagemagick.org/Usage/formats/#tiff

or some external to IM png optimizer so that you can see which gets compressed the most. That is if load time is an issue.

You can also try loading a precomputed and stored board or use the tiling method and just crop to the area you need or tile only to the size you need -- regarding your objection to using tiling or a precomputed board (again stored as mpc possibly if it is loaded over an over for each move from the same script)

[msasha]

The advantage is not for one move, but in using the stored mpc retrieved over and over for each move (along with clones so you don't have to load the same piece image over and over such as for pawns). The mpc can be stored as a temporary file and used throughout a script (that I assume you use to go from move to move). If you have to run the same commands for each move and cannot use a single script for the whole game, then you lose the advantage of the mpc when loading your images.

There is no game and there are no moves. The script just takes a single position, generates and returns an image of it.

But you should be able to use clones for each copy of any one piece rather than loading it from disk each time.

That is what I was hoping for when I preloaded all the piece images into mpr and then rendered the mpr images onto the board. But this was actually slower. I bet that if I profile it, I will see that it was slower by the exact amount of time it takes to preload the images into mpr (which means that drawing mpr and drawing png takes the same amount of time). This is actually not very unexpected, as the image files are very small, so the OS will have them entirely in memory cache after the first time they are read, with no disk-access for subsequent reads.

With regard to tiff, I was hoping there would be either an 8-bit color with 8-bit alpha version or atleast you can use a compressed 24-bit tiff with 8-bit alpha. But I am not an expert on either tiff or png. But see

http://www.imagemagick.org/Usage/formats/#png
http://www.imagemagick.org/Usage/formats/#tiff

or some external to IM png optimizer so that you can see which gets compressed the most. That is if load time is an issue.

You can also try loading a precomputed and stored board or use the tiling method and just crop to the area you need or tile only to the size you need -- regarding your objection to using tiling or a precomputed board (again stored as mpc possibly if it is loaded over an over for each move from the same script)

I don't think load time is an issue. As I mentioned, most of the time seems to be spent in drawing (I keep saying that, but I guess I have to do some work to prove it - I'm going to write some tests tomorrow), and is proportional to the amount of affected pixels. The piece images are quite small as well (around 1k, so they fit into 2-3 512-byte blocks), so I would actually think that compressing them can only make loading them slower (even if you can get them into 1 block, loading shouldn't be noticeably faster, but decompressing would be slower).

[fmw42]

That is what I was hoping for when I preloaded all the piece images into mpr and then rendered the mpr images onto the board. But this was actually slower. I bet that if I profile it, I will see that it was slower by the exact amount of time it takes to preload the images into mpr (which means that drawing mpr and drawing png takes the same amount of time). This is actually not very unexpected, as the image files are very small, so the OS will have them entirely in memory cache after the first time they are read, with no disk-access for subsequent reads.

Clones are not the same as creating mpr files, but the concept is similar. I don't know which is faster.

see

http://www.imagemagick.org/Usage/basics/#image_seq

"This is actually very fast, as "-clone" only clones the image meta-data, and not the image data itself. In a clone the data is only copied when it is also modified."