Conversion between IntPoint/DoublePoint and .net Point/PointF

[GoogleCodeExporter]

Describe the feature you are interested and which may bring benefit to the
project ...

Implement type conversion operators for the AForge point type IntPoint and 
DoublePoint to the native .net types in System.Drawing, i.e. AForge.IntPoint 
to/from System.Drawing.Point and AForge.DoublePoint to/from 
System.Drawing.PointF.

Alternatively - even better - stop using your own point structures and switch 
to Point and PointF.  If additional methods are required, they can implemented 
as extension methods to the framework types.

This is beneficial because the .net framework drawing methods which need to be 
used in parallel to AForge expect Point or PointF values, which at present need 
to be converted with user code each time they are used.  This is particularly 
awkward for lists or arrays of points.

Provide any references/links to publications/algorithms/etc. which could
help in development ...

The code is trivial: either introducing the appropriate Public Shared Widening 
Operator CType (VB.net syntax) to the point structures/classes, or removing 
them entirely and defining any necessary extension methods to Point and PointF.

Original issue reported on code.google.com by SimonCHo...@gmail.com on 12 Oct 2010 at 12:04

[GoogleCodeExporter]

Unfortunately, converting from double (DoublePoint) to float (PointF) is a 
information-losing conversion, and Microsoft's guidelines say that should not 
be done automatically.
Similarly, the removal of IntPoint and DoublePoint would be a breaking change, 
which should be done carefully, if at all.

Language-lawyer tendencies assuaged, I'd vote for breaking changes over 
automatic conversions between various functionally equivalent structures. 
Failing that, I'd also vote for truncating doubles to floats automatically.

If you (AForge devs) are opposed to such things, extension methods to convert 
IEnumerable<IntPoint> to IEnumerable<Point> and IEnumerable<DoublePoint> to 
IEnumerable<PointF> would make the array/list of points issue less problematic; 
it's easy enough to take an IEnumberable and convert it to the desired concrete 
class. Or to just use it as an IEnumerable.

Original comment by dales...@gmail.com on 12 Oct 2010 at 4:09

[GoogleCodeExporter]

I really agree that the fact AForge.NET framework has its own IntPoint and 
DoublePoint structures may look awkward and introduce pain. I can explain why 
they came ...

I simple don’t get why MS decided to put Point and PointF into 
Systtem.Drawing namespace.  Why should I reference this assembly and use this 
namespace if don’t want to draw at all? What if I want to create some 
math/geometry/whatever routines, which deal with points, but not with drawing?

Well, maybe the above though is not an excuse to introduce such awkwardness, 
but putting point structures into System.Drawing is not the best idea either.

Original comment by andrew.k...@gmail.com on 10 Nov 2010 at 10:51

[GoogleCodeExporter]

The reasoning behinds the decision to provide custom point structures outside 
System.Drawing makes sense. However, I think it would be useful to provide more 
of the methods implemented by System.Drawining.Point/PointF, in particular the 
Empty property to return a zero-valued point, and methods for truncating, 
ceiling and flooring a Point/DoublePoint. They could be marked as 
[Serializable] as well.

By the way, wouldn't it be better if X and Y were exposed as properties instead 
of public fields? Those would be optimized by the compiler anyway.

Original comment by cesarso...@gmail.com on 14 Apr 2011 at 2:20

[GoogleCodeExporter]

>> However, I think it would be useful to provide more of the methods 
implemented
>> by System.Drawining.Point/PointF, in particular the Empty property to return
>> a zero-valued point, and methods for truncating, ceiling and flooring a
>> Point/DoublePoint.
Yep, could be done. You can even submit a patch for this ;)

>> By the way, wouldn't it be better if X and Y were exposed as properties
>> instead of public fields?
We may do it. However the benefit is not that obvious in this particular case. 
Cannot imagine any type of extra code someday appearing in setter. (Take a look 
at XNA code - MS does not bother to create extra properties for simple 
structures like Vector3)

>> Those would be optimized by the compiler anyway.
Only JIT compiler may do it.

Original comment by andrew.k...@gmail.com on 17 Apr 2011 at 9:54