Port of aggdraw to agg 2.4

[dov]

• Move agg2 source directory to agg
• Update agg to 2.4
• Update aggdraw source to match and work with agg 2.4 interfaces
• Update tests to work with new code

[karimbahgat]

Is this the same as #48, which passed, but redone from scratch to make sure which agg version was the starting point (as discussed in #48)?
Any clue why appveyor failed but travis not (what's the difference)?

[djhoese]

@karimbahgat Yes this is a copy of #48, if you read the discussion there you'll see that @dov needed/wanted to start over to clean things up. As for appveyor failing and travis not, appveyor is for Windows testing. If you look at the logs it seems appveyor is using a bad compiler (or something) and doesn't recognize the C++ syntax for ::. I'm not a C++ expert, but I think this syntax has been around for a while so not sure why the Windows compiler isn't recognizing it.

@dov ideas?

[dov]

Ok. I seem to have fixed it. The problem is that windows.h by default defines macro for min() and max() that messes up the use of these functions in STL. You can prevent windows.h from defining these macros by a define. And this indeed seems to have solved the Windows compilation problem.

[djhoese]

@dov Any idea why agg main would not have run in to this issue?

[dov]

@djhoese What exactly do you mean by agg main? If you mean the agg C++ package, then I guess that they defined this variable in their visual studio settings, or cmake, or whatever they use for compiling under Windows. This is part of the windows compilation heuristics you learn to live with. Just do a google search for "NOMINMAX windows" and you'll see what I mean. In short, don't worry too much about it. :-)

[dov]

Thinking about it again, you can also define it in setup.py if you know how to create a CPPDEFINE for windows compilations. Personally I just found it easier to do it in the C++ source code.

[djhoese]

Yeah that's what I meant. I was initially alarmed by you modifying the headers files. I'm not that concerned about it so no need to change it. However, I do have some macro definitions in the setup.py already for the version number.

Hhhmmm maybe I'll try to do that on your branch unless you have time to tackle it.

[dov]

Ok. I moved the define to setup.py . Let's see if it passes the windows checks. (I admit that I don't have a working windows compilation environment for python modules on...)

[dov]

I have to admit that I don't understand these regression test failures. Import of numpy failed? What does that have to do with us?

[djhoese]

Looks like the conda-forge package is broken. There are multiple issues related to it like conda-forge/numpy-feedstock#127

[djhoese]

I've restarted the failing tests just to see if they pass now. Unlikely, but easiest way of "doing something" without doing anything.

[djhoese]

conda-forge/gfortran_impl_osx-64-feedstock#9

[djhoese]

Fixed!

[a-hurst]

This is great, fantastic work!

One small concern with the pull request in its current state: right now it behaves similarly to the old dov agg2.4 version in that it changes the default line-join and line-cap styles to “rounded”, which means that merging this request would cause unexpected visual changes in projects written with the existing aggdraw version (e.g. I know aggdraw was/is popular among some experimental psychologists for generating visual stimuli in Python experiments, and the rounding behaviour change would mean plenty of experiments suddenly looking different). Could I request that the defaults be changed back to the original line-join/line-cap behaviour for the sake of backwards compatibility?

[djhoese]

Ok, it's been long enough. I'm merging this to master. We'll wait a week to let anyone who would like to test off of the master branch do that, then I'll make a release and we'll see how many people have problems. Theoretically the agg C++ library should only fix functionality in newer versions, right? ...right?!?! That's how all software development goes. 😨

[a-hurst]

Main issue I'm foreseeing here is that the default line join and line cap type changes from square to rounded with the new 2.4 changes, unexpectedly changing previous default behaviour. It's also not clear from the docstrings or code what the different possible values/arguments for the 'linejoin' and 'linecap' args actually are, making the change extra disruptive since it's not obvious how to revert to the old behaviour.

Sometime within the next week, hopefully before the next PyPi wheels are uploaded, I'll open an issue with some screenshots demonstrating the difference, and do some more extensive testing with my aggdraw-dependent package to see if there are any other issues (everything else seemed to work fine last time I tested the 2.4 branch with it, though).

[djhoese]

@a-hurst I'm so sorry. I didn't see your comment from March. It would be great if you could make an issue mapping out the differences. If it is easy enough to set the defaults to the old behavior then I'm fine doing that (@mraspaud thoughts?).

@a-hurst What are your thoughts on a deprecation cycle? We could either have a function for "preserve legacy defaults" or in the other direction "use future defaults". Or, less likely, remove the default cap style and make users have to choose one...no that's a bad idea.