方針が決まってきたのでそれについて書きます。
概要
1. C++ コア部分
OpenGL や freetype、画像処理、座標演算などはすべてここで行われます。ここでは言語を超えるために C++ STL とは違う型が多用される予定です (もしそのままでうまくいく方法があればその限りではありません)。
基本的に普通の C++ と変わりません。ただし、一部の制約 (言語間プロジェクションを行うため) がかかる場合があります。
2. Obj-C/C++ 部分
Obj-C は Obj-C++ を経由し扱えるようになる予定です。これらはすべて自動生成される予定です。
C++ コア部分をラップして C++ STL に変換して利用できるようにするかは未定です。少なくとも内部では Rx-event で扱うための生構造は作る予定なのですが、これをわざわざ変換かけて C++ で、ってやるとコードが汚くなるので、C++ コアをラッピングして別にライブラリーとして形づくる可能性は検討しています。
3. Java/C# 部分
Java は BridJ を使うのでほぼ確定です。がしかし、やっててよくわからない挙動 (バグ?) がありました。
native void print( @Ptr long value );
はおｋなのに、
native void print( Pointer<XString> value );
はダメだということです。long は 64-bit に最適、であり、32-bit には非最適なので、これがよいのかわかりません。というか、まだ AMD64 な環境でしかテストできていないというのが現状です。こちらに関してはそのうちテストプログラムを公開する予定です。少なくとも、Java は Windows Desktop, OS X, Linux, Android での動作保障を予定しております。
次に C# ですが、現在検証中です。CXXI というものを使ってみてるんですが、いまいちうまく Binding できない… 例外が出てしまうという問題があります。少なくとも CXXI は BridJ よりも成熟していない気がします。
これら、JVM/CLR 上で動く言語にはいくつかの検討事項があり
などです。
xaml tree をいまだにどこに配置すればいいのか、と考えていて、特に xaml tree を C++ な native 界隈に置くと GC で不正に消えてしまうのでは？ とか思ったりしています。native 言語と JVM/CLR 言語で両方木を持つのは無駄ですし、各言語に乗せるのがよいのでしょうか？ しかし各言語に乗せるとなると座標演算のときの関数呼び出しでデメリットが非常に大きくなりそうです。
このあたりの問題をうまく解決しないと前に進まないので、ゆっくりアーキテクチャーを考える必要がありそうです。少なくとも、座標演算は一番大事な心臓なので、他が多少遅くなってもここを何としてでも早くしたいという思いがあります。
ちあみに C# は少なくとも Windows Desktop, OS X, Linux を予定しておりますが未定です…
4. まとめ
ということで 3 日ぐらい調査しながら今回の記事を書き上げたのですが、まだ確定というわけじゃないですが、BridJ や CXXI という素晴らしいプロダクトがあるのでこれを活かす方向性で動かしたい感じです。ただ、CXXI の問題 (うまく native C++ function を呼び出せない) が解決し、改めて記事を書かせてもらおうかな、と。
Java は Windows AMD64 で問題ないので、ほかのプラットフォームで検証するだけ。C# についてはもし解決できないようであれば、C# はサポート対象外として、C++ と Java、Obj-C/Swift に絞って開発しようかと思います。
もともと Windows 以外のプラットフォームに対する xaml を提供するのが目的であり、Windows の優先度が低いことのは事実です。てか、Windows はあくまで 1 開発環境としての環境整備の面が強いと考えています。Windows Desktop で Xxaml 動けば、他では xxaml.dll を libxxaml.so に変えてコピペすればおｋ、みたいなのを目指してる。これが一応最終ゴール。共有ライブラリーを変えるだけで他のプラットフォームで動くのは面白い試みだと思うし、少なくとも劣化版 xaml 程度のことはめざします。
最後に。CXXI の情報ください。動かし方わかりません。
以上。
