マネージドコードじゃ速度でないだろ。
AndroidもVM遅すぎて気がつけばC言語で書くのが普通になってしまっているし。

スマートフォンも気がつけばガラケー時代の開発手法に戻っている

>>451
ARMv7の1GHz以上のCPU上で動くのが約束されているからそこそこ速度出るよ。
VM自体も門外漢のGoogleが一から作ったモノと、JavaVMや.NETを何年も作ってきているMSじゃ経験が違うし。

それに機種やOSのバージョンが違っても互換性をかなり高く維持できるマネージコードは開発側から見ても魅力的。
セキュリティも高くなるし、Androidのアプリと端末毎の互換性・相性問題やマルウェア騒ぎを見ているとネイティブが必要か？って思う。

特にWMはネイティブアプリの互換性の所為で何年もWinCE5からWinCE6へカーネル変更を行えなかった過去があるし
今のWinCE6+7のWP7、WinCE7メインになりそうなWP7.5(Mango)、来年末のWP8とマネージコードで乗り越えたいんだと思う。

>>453
PC上でさえ遅いマネージドコードがARMでは絶望的だと思うけどねえ

現状ではピュアマネージドなコードなんて皆無だし
資産が何も無いに等しい

今ある資産はmarketplaceにある、10000のアプリだけ。

>>454
.NET の処理速度は意外と速いぞ？

ネイティブアプリで厳密な型チェックとかセキュアなメモリ・変数アクセス、
ガベージコレクション相当のメモリ管理とか行う場合と処理速度は大差ない。

起動時のJIT処理はネックだけどPCでは Ngen.exe でアイドルタイムにプリコンパイルしておけるし
WP7（というかスマホ）は基本ずっと起動しっぱなしなので問題になりにくい。

実際に行ってるかは知らないがスマホはCPUやメモリ容量が変わらないから
インストールの時点でプリコンパイルして実行ファイルとして保存してしまう手もあるし。

.NET Frameworkの知識だけで書き込んでる奴がいるみたいなんでツッコミ

>>453
.NET Frameworkならともかく.NET Compact Frameworkはそんなにいいもんじゃないぞ。
本家.NETと比べサポートされるAPIがあまりに限定されてて涙が出そうになる。
また新OS機能対応もさっぱりで気の利いたことやろうとするとp/invokeがほぼ必須という笑えない状態だった(WindowsMobile時点ね)
あとCE6カーネルへの移行が遅れたのはマーケティング上の失敗が主原因だろう
デバイスドライバならともかくアプリの互換性に(ネイティブアプリでさえ)大きな問題はないよ

>>457
.NET Compact Framework用にngen.exeはないからプリコンパイル出来ない。
アプリも起動しっぱなしじゃないから起動の遅さは大問題だよ
CE6でもメモリのスワップ機能はないから同時に実行可能なアプリ数はかなり制限されるからね
> スマホはCPUやメモリ容量が変わらない
ご冗談を。最低スペック、推奨スペックが決まってるだけでCPUならARMv5～ARMv7までサポートしてるよ

実機触らないで騒いでいるヤツが多いな。
実際に作成するとわかるが、リストボックスコントロールが重い。
ページングを自分で実装する必要がある。
とりあえず、開発環境はすぐにでも手にいれられるから、試してみろよ。

>>458
WP7はフルセットSilverlight 3 + WPFですが何か？
色々と制限はあるけど.NET CFみたいな非互換サブセットとは違うし、そもそも453で.NETの話をしてない。

CE6カーネルは再コンパイルなしじゃ動かないアプリが無視できないくらいだと聞くけどどうなんでしょ？
XP SP3→Vista のアプリ互換率 83% でもダメOSの烙印押されたのにスマホで通用するレベルでしたか？

メモリに関してはWM時代とは違う。てかWP7の話をしようよ。
同時起動プロセス制限は1024倍、最大メモリも8倍以上でマルチタスク禁止だから終了しなくても済む可能性はかなり高くなる。

>> スマホはCPUやメモリ容量が変わらない
>ご冗談を。最低スペック、推奨スペックが決まってるだけでCPUならARMv5～ARMv7までサポートしてるよ

ご冗談を。同じ端末でインストール時と実行時でCPUやメモリ容量が変わるのですか？

>>459
ListBoxよりもStackPanelを使うと高速化できる
http://d.hatena.ne.jp/kabakiyo/20101121/1290334719

ListBox Scroll Performance - Do not use ListBox**
http://blogs.msdn.com/b/slmperf/archive/2010/10/06/silverlight-for-windows-phone-7-listbox-scroll-performance.aspx

Listboxからstackpanelに変えても、パフォーマンスが悪いよ。
リンク先のアプリを実機テストするとスクロール感度がひどい。
ローカルDBもサポートされてないから、ファイルベースで管理というのは…
せめて、sqlliteサポートして欲しい。

Phone 7 に届くまで #36：ないのなら作ってしまえ - WP7 SqliteClient Preview
http://blogs.msdn.com/b/shintak/archive/2010/08/31/10055921.aspx

解決策があるのならいいが、mediaelementのデバッグを教えて欲しい。実機が繋がっているとメディア操作が一切出来なくなります。

XNA メディア ライブラリを代わりに使ってみるのはどうだろう？

10 行でズバリ!! [C#] XNA メディア ライブラリの利用
http://code.msdn.microsoft.com/10-C-XNA-246e4371/

Microsoft.Xna.Framework.Media 名前空間
http://msdn.microsoft.com/ja-jp/library/dd254868.aspx

実機持ってないからデバッグできるかは知らない。

>>457
単純ループとか絶望的なくらい遅いじゃん。
Androidもそれが原因で2D画像処理アプリが壊滅してたわけで

C#で単純ループが遅いって、そりゃ何か作り方間違ってる。
ループの内側で参照型のインスタンス生成しまくってるとかないよね？

遅いというソース出してもらわないと

Javaの場合ポインターが使えなくて画像処理が多少遅いってのはよくある話。

C#はポインタがあるから関係ない話。

unsafeでポインタを使うよりunsafeで多次元配列（[i,j] ≠ [i][j]）使った方が速いこともあるけどな。

画像処理なんか素直に作ったらC++でも遅いわ
SSEとかエグい最適化しないと

C# + Silverlight 3 の画像処理サンプル
http://efvincent.com/poc/strangeattractor/

上記を並列化して最適化した物（将来マルチコア搭載スマホがでたら有効）
http://efvincent.com/poc/strangeattractor/


最適化されたAdobe Flexと比べたら一目瞭然。
http://www.joa-ebert.com/swf/index.php?swf=alchemy/Example03

>>472
一つ目のアドレスみすった。

C# + Silverlight 3 の画像処理サンプル
http://www.joa-ebert.com/files/xpa/attractor/

>>460
ツッコミどころが多すぎるぜ、、、

> WP7はフルセットSilverlight 3 + WPFですが何か？
全然フルセットじゃないんだけど

Differences Between Silverlight and Silverlight for Windows Phone
http://msdn.microsoft.com/en-us/library/ff426930(VS.95).aspx

WP7ではブラウザ内実行も出来ないくせにファイルアクセスは分離ストレージ
のみとか予定表データにアクセスできないとか外部アプリ実行できないとか
セキュリティだけは本家並みにする神経は理解しかねる。

> 色々と制限はあるけど.NET CFみたいな非互換サブセットとは違うし、そもそも453で.NETの話をしてない。
.NET CFは非互換サブセットじゃない、.NET極小サブセット+固有機能という感じ。使用するクラス/APIを慎重に選べば
WindowsPCでも動作するものは作れる、あまり意味は無いが。それから453で.NETの話をしてないのなら
> JavaVMや.NETを何年も作ってきているMSじゃ経験が違うし。
のあたりは何を言ってるのかな?モバイルで.NET CF以外の経験あんの?

> CE6カーネルは再コンパイルなしじゃ動かないアプリが無視できないくらいだと聞くけどどうなんでしょ？
> XP SP3→Vista のアプリ互換率 83% でもダメOSの烙印押されたのにスマホで通用するレベルでしたか？
WEC7(ARM+標準シェル構成)でもCE4.1のSig3用アプリ(exe)がほぼ動作する程度には互換性があります。
マネージドなWP7アプリは再コンパイルどころかソース修正ほぼ必須みたいですが？

Porting Silverlight-Based Applications to Windows Phone
http://msdn.microsoft.com/en-us/library/ff955493(VS.95).aspx

続く

>>460
ツッコミの続き

> メモリに関してはWM時代とは違う。てかWP7の話をしようよ。
> 同時起動プロセス制限は1024倍、最大メモリも8倍以上でマルチタスク禁止だから終了しなくても済む可能性はかなり高くなる。
え？WP7とWindowsPCを比較してるだけだよ。あとメモリ8倍以上てのは1プロセスあたりの仮想空間の話か？それなら物理メモリ不足に効果ないぞ。
というか453では
> WP7（というかスマホ）は基本ずっと起動しっぱなし
って言っておいて「マルチタスク禁止だから」じゃ話が矛盾してるよ？
年内予定のアップデートでもiPhoneやAndroid同様のノンプリエンプティブマルチタスクだろうし
そうなるとWP7マネージドアプリ起動速度はCE6カーネルの恩恵は小さいように思えるんだが

> ご冗談を。同じ端末でインストール時と実行時でCPUやメモリ容量が変わるのですか？
そんなのスマホじゃなくてPCでも変わらないでしょ。そもそも458では
> スマホはCPUやメモリ容量が変わらないからインストールの時点でプリコンパイル
って書いてるのはどういう意味なのかな？PCだと無理だけどWP7なら可能なの？

別にWP7はやめとけというつもりはないが勝手に桃源郷を夢見ない方がいいぞ
MSのエバンジェリスト高橋氏が否定的とも思えるエントリあげてることからもお察しって奴だ

Phone 7 に届くまで #17：WP7 でできないこと
http://blogs.msdn.com/b/shintak/archive/2010/07/21/10040365.aspx
Phone 7 に届くまで#21：必要なのは開発者のマインドチェンジ
http://blogs.msdn.com/b/shintak/archive/2010/07/23/10041725.aspx

C#+Silverlightの生産性の良さは実感できるが、参入メーカーの少なさやデフォルトのコントロールデザインがまず過ぎる。
スライダーコントロールの下マージン取り過ぎ。タッチ領域くらい開発者で決めさせて欲しい。

>>475

その高橋氏に書かれてるし。
http://blogs.msdn.com/b/shintak/archive/2011/03/20/10143414.aspx

多分みてるんだね。ここ。

>>477
エバンジェリストのBlogとは思えないほどの負の雰囲気が溢れていて、ちょっと笑った
何かあったのかいな

日本からの要求が本国に通らなくてイライラ溜まってたり、とかってのはありそーねー。

東電が電気使用状況データをCSVで公開　「アプリ作ったら知らせて」と経産省
http://www.itmedia.co.jp/news/articles/1103/24/news068.html

出番みたいだぞおまえら

東電に責任を取らせる文言を埋め込んだアプリを作ろう

東電会長と社長の悪口がランダムに表示されるアプリとか？

東電幹部のフランス講座を受けれるアプリとか
保安院が解説するキン肉マンの王者決定戦が見れるとか

2chブラウザ作ってくれ。

日本語版 Windows Phone 7 の実機画像を初公開 - ななふぉ
http://nanapho.jp/archives/2011/04/wp7-japanese-images-for-april-1st/

日本のみなさん、お待たせしました。
実機で動作している Windows Phone 7 日本語版に触れる機会がありましたので、さっそくその様子をご紹介します。

きたー

ぶっちゃけ不評な.NET CFよりもsilverlghtの制限のほうがきつくないか？
ソケットつかえんのが痛すぎる。WP7になってサーバとしてはもちろんのこと
（HTTP以外の）クライアントとしてすらまともな通信できなくなってる。
あと、ファイルシステムアクセス、DataTalbeなどデータベース関連、PINVOKEが
できないのも致命的。

Silverlightだからそういう制限があるんじゃなくて意図的な制限だよ
PC版のSilverlightとは別物

誤解されそうだな
もちろんPC版でもできないけど
もともとPC版とは異なるものなのでPC版でできないからWP7でもできないという必然性はないってこと

ソケットは年末の大型アップデート"Mango"あたりで解放される方向で進んでる。
ファイルシステムは従来のものとは互換性がない（ように見せている）から仕方ないか。
データベース関連はC#-SQLiteかXML-DBとLinq to XMLでどうにかするしかないんじゃね？

P/Invokeは今後WP7.5、WP8とバージョンアップやAtom対応の可能性とか考えると今後も対応しそうにないな。

いや、基本はPC版と同じだし、そのためのsilverlightだろ。。。
機能を付加することもできるのにあえてしてないってのは正しいのだろうけど
その意図的な制限ってなんのためか説明できる？
P/Invoke制限にゃ多少妥当性あると思うけど、それ以外はサパーリだわ。
はっきりいって劣化以外の何物でも無いと思うんだけど。

>>490
ソケット解放はうれしいよね。でも、待ち受け（サーバ）もちゃんと
させてくれるんだろうか。あと微々たることだけど、
silverlightだとTcpClientクラスとかがないのもCFより移植面倒…。
DataTableないのも面倒。データベース関連はしっかり整えたほうが
スタンドアロンで使えて、ネット志向のandroidと差別化しやすいのに。

データはサーバー上に置く前提だから、分離ストレージ以上のファイルシステムは要らないって思想でしょ。
TcpClient ないのは、携帯機器だと常時接続は消費電力食うだけだし、Notification Service使えと。

>>466-468
http://hibari.2ch.net/test/read.cgi/tech/1294921393/32

>>469-470
ポインタ云々なんか以前にC#もJavaも単純ループが遅いからな。

>>471
スマートフォンの小さな画面向けなら解像度もしれてるし、予め
縮小してデータを削ってしまうのが正解かと。

>>472-473
Opteron8コアでも40フレームしか出ないぞ。
ソースも覗いてみたが W550 x H400 というサイズの画像処理で
これだとARMでは絶望的だろ。たしかにFlash比では速いが。

結論からすると単純ループを多用する2D画像処理は無理だな。
GPU支援が得られるようなゲームなんかは関係ないだろうけど。
≒医療関係は壊滅的

リアルタイムで2D画像を生成しなければならない医療みたいな分野での利用は絶望的。
マネージドコードでは↓のレベルに達するのに100年かかるレベル。
http://www.newton-graphics.co.jp/osirix

>>494
なぜそんな物をソースに選んだ？
お前C/C++使えないだろ。釣り？荒らし？

>>494-495
確かに医療用やリアルタイム性を要求される画像処理には向かないだろうが
それを Windows Phone 7 を積んだ携帯電話で行う必然性は？

ついでに言うと医療用にタブレットとして出すならメーカーがネイティブアプリを作るから問題ないよ？
そして医療用やリアルタイムな画像処理には専用DSPぐらい積むよ？


あとC#の単純ループが遅いとかC#のプログラム出来ないだろｗ

http://d.hatena.ne.jp/lovepotion/20090828/1251461808
＞1024×1024ぐらいでのかけ算と足し算とメモリー参照の速度
＞単純なループ処理でのメモリーテストでは、C++1.265秒、C#だと1.500秒でした。

足し算だけのループだとC++の２倍程度の処理時間で済むし、画像処理で加減算だけって考えにくいよね。

>>494
リンク先のソース見てきた。
こいつC#っていうプログラミング言語を理解してないだろ？

これが遅いのはビットマップアクセス方法でわざわざ遅い手段を選んでいたり、
不用意にポインタを多用＆インクリメントしていたり、キャストを多用していたりしてるからだろ。

>>498
いやあれC++でも遅いと思うぞ
条件分岐のせい

>>496ｰ499
医療分野は画像処理を含めー既にiPhone/iPadの牙城となっている。
つまりポンコツiPhone3系ですら余裕で実現していた分野だ。
ハイスペックなハードウェアをもってしてもiPhone3にすら及ばないとかマネージドコードの足枷は大きすぎる。