How to proceed with libjpeg support on Windows

[vweevers]

As GTK no longer bundles libjpeg, jpeg support needs to be fixed. There are multiple solutions to this:

1. Use the *.lib files (and includes) from libjpeg-turbo.
   • User must download libjpeg-turbo-1.3.1-vc.exe (or the 64bit version), which by defaults installs to C:\libjpeg-turbo. See my fork for a working example. This is similar to how GTK is included, except that I did a static include, because it's a small thing. Note, I forked from 1.1.3 because master fails to build on windows.
2. Use sources of original libjpeg
   • Because it's a zip file (1 MB), we could automatically download it as part of the build process, unzip with a Python script (no extra deps) and then build it to jpeg.lib.
   • Building it (outside of node-canvas and gyp) is simple (nmake /f makefile.vc setup-v10 && nmake /f makefile.vc nodebug=1 libjpeg.lib). I think it's feasible to rewrite the makefile stuff as a gyp target.. well, worth a try, at least. Make that target a dependency if OS=="win" and everything is awesome.

What's standard practice for dependencies like these? Except ignoring windows. Thoughts?

[vweevers]

Same thing for gif, BTW. I personally don't need gif support now, but I'd be happy to look at that later, once I know what the best practice is.

[kkoopa]

Libjpeg-turbo is probably to prefer from a performance point of view.

[scarletsky]

@vweevers
Do you build node-canvas successfully with libjpeg on Windows?
I've tried to build libjpeg from sources, and add libjpeg's path to binding.gyp and set with_jpeg to true. But I still failed to build node-canvas with jpeg.

[vweevers]

Below is copied from my binding.gyp. Using libjpeg-turbo, but same works with libjpeg. Just make sure to use the static library.

Under variables:

'libjpeg_root%': 'C:/libjpeg-turbo',
'with_jpeg%': 'true'

Under target:

['with_jpeg=="true"', {
  'defines': [
    'HAVE_JPEG'
  ],
  'conditions': [
    ['OS=="win"', {
      'libraries': [
        '-l<(libjpeg_root)/lib/jpeg-static.lib'
      ],
      'include_dirs': [
        '<(libjpeg_root)/include'
      ]
    }, {
      'libraries': [
        '-ljpeg'
      ]
    }]
  ]
}]

[vweevers]

libjpeg-turbo is easy and fast. Closing this.

[scarletsky]

@vweevers
When I try to rebuild canvas, I saw some warning information.

  Canvas.cc
  CanvasGradient.cc
  CanvasPattern.cc
  CanvasRenderingContext2d.cc
  color.cc
  Image.cc
  ImageData.cc
  ---------- warning start ----------
..\src\Image.cc(810): warning C4146: unary minus operator applied to unsigned t
ype, result still unsigned [C:\Users\Administrator\canvastest\node_modules\canv
as\build\canvas.vcxproj]
..\src\Image.cc(661): warning C4505: 'jpeg_mem_src' : unreferenced local functi
on has been removed [C:\Users\Administrator\canvastest\node_modules\canvas\buil
d\canvas.vcxproj]
  ---------- warning end ----------
  init.cc
  PixelArray.cc
     Creating library C:\Users\Administrator\canvastest\node_modules\canvas\bui
  ld\Release\canvas.lib and object C:\Users\Administrator\canvastest\node_modul
  es\canvas\build\Release\canvas.exp
  Generating code
  Finished generating code
  canvas.vcxproj -> C:\Users\Administrator\canvastest\node_modules\canvas\build
  \Release\\canvas.node
gyp info ok

Does it make any sense?

[vweevers]

Don't know about the first, 2nd one looks like simple cleanup (and if so, an unnecessary warning if you ask me). To be honest, I don't even look at VS warnings any more. I see em with other native modules too, most of the time it doesn't mean anything. You only need to worry when some specific feature doesn't work.

[scarletsky]

@vweevers I see, thank you