Bug 18666 - OpenTK-1.0 library in Xamarin.Android 4.12.1 missing three year old bugfix in Vector3.TransformPerspective
Summary: OpenTK-1.0 library in Xamarin.Android 4.12.1 missing three year old bugfix in...
Alias: None
Product: Android
Classification: Xamarin
Component: BCL Class Libraries ()
Version: 4.12.0
Hardware: Macintosh Mac OS
: Normal normal
Target Milestone: ---
Assignee: Radek Doulik
Depends on:
Reported: 2014-03-31 10:29 UTC by James Athey
Modified: 2015-03-02 16:02 UTC (History)
2 users (show)

Is this bug a regression?: ---
Last known good build:

Notice (2018-05-24): bugzilla.xamarin.com is now in read-only mode.

Please join us on Visual Studio Developer Community and in the Xamarin and Mono organizations on GitHub to continue tracking issues. Bugzilla will remain available for reference in read-only mode. We will continue to work on open Bugzilla bugs, copy them to the new locations as needed for follow-up, and add the new items under Related Links.

Our sincere thanks to everyone who has contributed on this bug tracker over the years. Thanks also for your understanding as we make these adjustments and improvements for the future.

Please create a new report on Developer Community or GitHub with your current version information, steps to reproduce, and relevant error messages or log files if you are hitting an issue that looks similar to this resolved bug and you do not yet see a matching new report.

Related Links:

Description James Athey 2014-03-31 10:29:40 UTC
We recently tripped over a bug in Xamarin.Android’s OpenTK library.  The function in question is OpenTK.Vector3.TransformPerspective(), where an XYZ Vector3 is converted to an XYZW Vector4, except that the Vector4’s W coordinate is wrongly initialized to 0 instead of 1.

Here’s the bug fix, committed to OpenTK’s master branch on November 20, 2010:

It changes the TransformPerspective function to set the W coordinate of the Vector4 to 1, like so:

public static void TransformPerspective (ref Vector3 vec, ref Matrix4 mat, out Vector3 result)
	Vector4 vector = new Vector4(vec, 1);
	Vector4.Transform(ref vector, ref mat, out vector);
	result.X = vector.X / vector.W;
	result.Y = vector.Y / vector.W;
	result.Z = vector.Z / vector.W;

OpenTK’s Xamarin branch on github also appears to have had that bug fix for a long time, but that's definitely not what's in Xamarin.Android.  Here's what I see in the Assembly Browser for that function:

public static void TransformPerspective (ref Vector3 vec, ref Matrix4 mat, out Vector3 result)
	Vector4 vector = new Vector4(vec);
	Vector4.Transform(ref vector, ref mat, out vector);
	result.X = vector.X / vector.W;
	result.Y = vector.Y / vector.W;
	result.Z = vector.Z / vector.W;

There's an otherwise identical function that takes a Matrix4d instead of a Matrix4 that needs the same bugfix.
Comment 1 Udham Singh 2014-03-31 13:43:35 UTC
I have checked this issue. As per my observation I have noticed that implementation for "TransformPerspective" function has been changed into Assembly.

Screencast: http://screencast.com/t/8MJWFpv4

Environment Info :

=== Xamarin Studio ===

Version 4.2.3 (build 60)
Installation UUID: 011d70a5-dede-428b-ab04-ef451c2e539d
 Mono 3.2.6 ((no/9b58377)
 GTK+ 2.24.23 theme: Raleigh
 GTK# (
 Package version: 302060000

=== Apple Developer Tools ===

Xcode 5.1 (5035)
Build 5B45j

=== Xamarin.iOS ===

Version: (Enterprise Edition)
Hash: 58c3efa
Build date: 2014-10-03 18:02:26-0400

=== Xamarin.Mac ===

Xamarin.Mac: Not Installed

=== Xamarin.Android ===

Version: 4.12.1 (Enterprise Edition)
Android SDK: /Users/MM/Desktop/android-sdk-macosx
 Supported Android versions:
  2.1   (API level 7)
  2.2   (API level 8)
  2.3   (API level 10)
  3.1   (API level 12)
  3.2   (API level 13)
  4.0   (API level 14)
  4.0.3 (API level 15)
  4.1   (API level 16)
  4.2   (API level 17)
  4.3   (API level 18)
  4.4   (API level 19)
Java SDK: /usr
java version "1.6.0_65"
Java(TM) SE Runtime Environment (build 1.6.0_65-b14-462-11M4609)
Java HotSpot(TM) 64-Bit Server VM (build 20.65-b04-462, mixed mode)

=== Build Information ===

Release ID: 402030060
Git revision: 30c4afc300c2a39ec5300851357ce02e49dd217e
Build date: 2014-03-05 22:09:33+0000
Xamarin addins: f8a9589b57c2bfab2ccd73c880e7ad81e3ecf044

=== Operating System ===

Mac OS X 10.9.2
Darwin MacMini.local 13.1.0 Darwin Kernel Version 13.1.0
    Thu Jan 16 19:40:37 PST 2014
    root:xnu-2422.90.20~2/RELEASE_X86_64 x86_64

Please let me know if i am missing any thing.
Comment 2 James Athey 2014-03-31 16:46:28 UTC

No, you're not missing anything.  It looks like your project references OpenTK (v, while our project references OpenTK-1.0 (v

Is OpenTK actually newer than OpenTK-1.0, even though its assembly version number is lower?
Comment 3 James Athey 2014-03-31 16:56:06 UTC

I just downloaded the source to OpenTK- from OpenTK's sourceforge page http://sourceforge.net/projects/opentk/files/opentk/ , and from that, I can conclude:

* that source matches the source you showed in your screencast.
* OpenTK is older than OpenTK-1.0.
* The bug in question was introduced at some point between and version 1.0.

I will rename the bug to make it clear that this bug applies to OpenTK-1.0, not just OpenTK.
Comment 4 Jonathan Pryor 2014-03-31 16:58:53 UTC
@James: Our OpenTK versioning is...funky. (It's arguably a reason we should "productize" the assembly name to e.g. Xamarin.OpenTK-1.0.dll, but that would break all existing assembly references.)

So, hysterical raisons:

Once upon a time, OpenTK 0.9 was the current OpenTK, and this was used in MonoTouch 1.0 (and before 1.0).

OpenTK 1.0 was released, but it had a different API than OpenTK 0.9. Consequently, we kept OpenTK.dll as OpenTK 0.9 (preserving backward compatibility), and added OpenTK-1.0.dll (for the OpenTK 1.0 API).

Somewhere in there, Mono for Android was released, which included _both_ OpenTK.dll and OpenTK-1.0.dll, to assist in porting existing MonoTouch code. (Which was probably a brain-damanged thing to do, given that the OpenTK-1.0.dll API differed between iOS & Android, and I can only guess at the API differences in OpenTK.dll.)

Meanwhile, Radek set about "unifying" the APIs between iOS & Android so that they'd -- gasp! -- have compatible APIs, allowing OpenTK to be more easily/sanely ported between the Android & iOS. This work has not been released yet, but should land in Xamarin.Android 4.14 and some future Xamarin.iOS version.

Meanwhile meanwhile, the upstream opentk project went dormant (during which the mono/opentk github repo was created). Then it came back to life. Now it has a "OpenTK 1.1" version...which has an API incompatible with OpenTK 1.0. (Meaning they're breaking the framework version guidelines; if they break API, it should be 2.0!) What upstream will do in the future is unknown.

That said, Radek has the joyful task of tracking upstream and cherry-picking any API updates which are compatible with our current OpenTK-1.0.dll API, until such time as we need to break API for OpenTK-2.0.dll, whenever that happens (if ever).

Clear as mud?
Comment 5 Radek Doulik 2015-03-02 16:02:23 UTC
This was fixed some time ago, when we unified OpenTK-1.0 between Xamarin.Android and Xamarin.iOS => closing