のくす牧場
コンテンツ
牧場内検索
カウンタ
総計:127,062,774人
昨日:no data人
今日:
最近の注目
人気の最安値情報

    元スレ【Silverlight】Windows Phone 7 アプリ開発スレ

    silverlight覧 / PC版 /
    スレッド評価: スレッド評価について
    みんなの評価 :
    タグ : 追加: タグについて ※前スレ・次スレは、スレ番号だけ登録。駄スレにはタグつけず、スレ評価を。荒らしタグにはタグで対抗せず、タグ減点を。
    ←前へ 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 次へ→ / 要望・削除依頼は掲示板へ / 管理情報はtwitter

    451 = :

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

    452 = :

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

    453 = :

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

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

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

    454 = :

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

    455 = :

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

    457 = :

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

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

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

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

    458 = :

    .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までサポートしてるよ

    459 = :

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

    461 = :

    >>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

    462 = :

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

    464 = :

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

    465 = :

    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

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

    466 = :

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

    467 = :

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

    468 = :

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

    469 = :

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

    471 = :

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

    472 = :

    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

    475 = :

    >>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

    476 = :

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

    477 = :

    >>475

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

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

    478 = :

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

    479 = :

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

    480 = :

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

    出番みたいだぞおまえら

    481 = :

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

    482 = :

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

    483 = :

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

    485 = :

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

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

    486 = :

    きたー

    487 = :

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

    488 = :

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

    489 = :

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

    490 = :

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

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

    491 = :

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

    492 = :

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

    493 = :

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

    494 = :

    >>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支援が得られるようなゲームなんかは関係ないだろうけど。
    ≒医療関係は壊滅的

    495 = :

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

    496 = :

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

    497 = :

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

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


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

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

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

    498 = :

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

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

    499 = :

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

    500 = :

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


    ←前へ 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 次へ→ / 要望・削除依頼は掲示板へ / 管理情報はtwitterで / silverlight一覧へ
    スレッド評価: スレッド評価について
    みんなの評価 :
    タグ : 追加: タグについて ※前スレ・次スレは、スレ番号だけ登録。駄スレにはタグつけず、スレ評価を。荒らしタグにはタグで対抗せず、タグ減点を。

    類似してるかもしれないスレッド


    トップメニューへ / →のくす牧場書庫について