Gmagick support

[markoheijnen]

In 3.5 we added Imagick support. It would be great to also include Gmagick. Since Graphicmagick is just more awesome then ImageMagick.

[markoheijnen]

First try. Code from ​http://wordpress.org/extend/plugins/gmagick/

[nacin]

Sweet.

[dh-shredder]

If we're going to go for Gmagick support in 3.6, I'd suggest dropping it in for a soak as soon as we can, so that we can discover any hosting compatibility issues that might arise.

My only hesitation would be that there's less hosting support for Gmagick than Imagick. That said, it's pretty clear that Gmagick/Graphicsmagick is the way forward, both due to its developers support, and performance concerns.

[markoheijnen]

Change version number to 3.6.0 and also add [23750] to this patch

[markoheijnen]

Can we commit this? The code is pretty robust because it's almost the same at imagick. We do need user tests. I'm already running this code before 3.5 was even launched and never had issues.

[dh-shredder]

Same patch, but with Gmagick last in line.

[dh-shredder]

As requested in dev chat, same patch, but with Gmagick last in line: 23331.3.diff​

[nacin]

We load all core editors, even if we chose an earlier one first. So let's do this in 3.7, possibly reworking this to only include gmagick when it makes sense. Unfortunately we can't stop including GD and IM as classes may already be extending them.

[markoheijnen]

Don't see why it needs to get another flow. Loading the editors isn't something really heavy.

[wonderboymusic]

these are all marked 3.7-early

[nacin]

I've chatted with markoheijnen about this. According to some research, Gmagick has an install base of roughly 0% of WordPress sites. (The same sampling showed that GD was available on 95-98%+ of installs, Imagick on 25%.) So for the time being, this belongs in a plugin.