WPFでいうところのRenderTargetBitmapの役割を兼ねてるからな

シェーダーの結果をWriteableBitmapに書き込む方法ありませんか？

WriteableBitmap.Render

ICloneableが消えたのはなんでなんだろう。
どうせCloneの動作は激しく実装依存だからインターフェイスで形だけ合わせたところで
あまり意味がないからかなやっぱり。

詳細と簡易のどちらかも決まっていないので、
MemberwiseCloneと大して変わらないからなあ。
JavaにCloneableがあるから、こっちにも一応用意しておきましたってレベルな気がする。

具体的に型指定せずにICloneable型として扱うことなんてまず無いもんな
Cloneが具体的にどういう動作をするのか，どういう使い方を想定して実装するべきなのかについて
指針が全く無いから使いようがない

どん兵衛にはワカメが入っている。
それは開発者がどうしても入れたいと上司に掛け合った結果。
ワカメを入れることで食べる側に更なる味と健康を顧客達に。
そう強く願う開発者の善意がどん兵衛にワカメを入れたのだ。
高がワカメ、されどワカメ。
そのワカメに救われた人間がこの世にどれだけ居るだろうかっ！

誤爆ｽﾏｿ

何という誤爆w

和んだｗ

熱い誤爆だなｗ

ICloneableに熱い思いが入ってたのかと思った。

Microsoft Silverlight 3 オフライン ドキュメント
http://www.microsoft.com/downloads/details.aspx?FamilyID=0a9773a7-c854-41fa-b73d-535abfb73baf&DisplayLang=ja

もしかして Silverlight 3 のオフラインドキュメントは chm オンリー？

Silverlight 2 SDK の時みたく dexplorer からドキュメントを覗けたりはできなくなったのか…。

http://www.soulsolutions.com.au/Blog/tabid/73/EntryId/615/Traffic-in-the-Cloud-powered-by-Bing-Maps-Silverlight-and-DeepEarth.aspx
http://tc.soulsolutions.com.au/

海外のほうがこういうのは
なんぼか進んでるような気がする…

Silverlight2のプロジェクトを3でコンパイルし直したら普通に動いたんで、
まあいいかと思ってたんだけど、ふと調べてみたら
リンクしてるアセンブリのバージョンがいくつか違うのな。
心なしか、高負荷のアプリを動かした時のブラウザのリサイズが早くなった気もする。

WriteableBitmap.Renderすごい。ツリーに登録しなくてオブジェクトをどんどん描ける。
実質オブジェクトツリーから解放された気になってるんだけど、
Hitが無いとか、オブジェクトに依存する事以外でなんか問題ある？

SilverSpriteってWriteableBitmap対応してるらしいけど
SpriteBatch.Drawで使ってくれてるのかな？

WriteableBitmap.Renderの使い道は更新されない複雑な要素をキャッシュするくらいだろ
毎フレームWriteableBitmapを更新するようなことは非効率すぎる

となると、例えばパーティクルを表現しようとした時、
表示される最大オブジェクトを用意しておいて
毎フレーム表示、非表示を切り替えたり表示の優先順位でツリーの枝を移動した方が効率的？
なんか、枝の移動って処理的に重そうなイメージがあるんだけど。。

優先度ならツリーの移動なんて必要ないでしょ。
ZIndexを指定すればいい。

ああそっか。しかし山盛りの描画物を１つ１つ管理した方が良いってのは何か解せない。
特にオブジェクトに付随するイベントとか描画以外の部分も考えると。
もちろん、俺の知らない何かを見落としてるのかもしれない。
WriteableBitmap.Renderが通常のツリー描画に比べて
どれくらいパフォーマンスが落ちるっていう文献、どっかにない？

ツリー描画というのがどういうことをいうのかわからないが、
>>320を例として
もし、Image UIElementをパーティクルの個数分用意してImage UIElementを動かすといった場合、
80個ぐらいが限度かも。それ以上になるとフレームレートが落ちる。
BitmapImageオブジェクトで描画を行う場合は、PngEncoderなどSetSourceでのMemoryStreamによる描画より
WritableBitmapを使って描画するほうが早い。
(SL2はそもそもWritableBitmapがなかったからMemoryStreamでしかできなったけど)
ただ、パーティクルがピクセルごとの計算で実装できるものであればカスタムピクセルシェーダーで実装したほうがめちゃはやい。

あ、BitmapImageオブジェクトの場合は、描画内容(描画で使用する計算量)にもよるが、
だいたい500x500ピクセルぐらいが限度かと。それ以上になるとフレームレートが落ちる。(バックバッファ未使用)

だよなぁ。
>>319の
>毎フレームWriteableBitmapを更新するようなことは非効率すぎる
の根拠はどこからくるんだろう？一回バッファに描く所か？

すまん、ツリー描画というのはどういう描画のことなんだ？

すれ汚しですまん。最大の要因を忘れてた。
「マシンスペックによって描画速度は大きく変化する」
CPUのスペックによるといったほうがいいか。
８０個ぐらいとか、500x500というのはデスクトップマシンでの話し。
デスクトップマシン(Q6600,2.4GHz)とノート(Pentium M,1.2GHz)で同じものを動かして比べてみると、
ノートはデスクトップマシンの半分以下のフレームレートに落ちる。
また、ピクセルシェーダーはシングルコアにおいても描画速度は速いが、
マルチコアによる演算に対応しているため、コア数が多いCPUだとさらに描画速度が速くなる（ほぼｘコア数の速度となる）

>>326
ああごめん、CanvasとかにChildren.Addして描画する普通の描画方法。
ヘルプのパフォーマンスの項にツリーっていう単語がでてたんで、
これで通用すると思った。

>>328
そういうことね。わかった。

今から業務用アプリ開発するならSilverlight2とSilverlight3とどちらがいいですか？
普通なら新しい方を選択すべきでしょうが3は出たばかりで不安です。
早まるなFlashにしろ！という意見もお待ちしております。

業務用アプリならblendは使わないよな？
blendなしでいいなら、俺は3を選ぶな。

> 普通なら新しい方を選択すべきでしょうが3は出たばかりで不安です。
3が不安なら2も同じくらい不安じゃね？
どうせ大した実績もないんだし。

むしろ、2のサポートが続けられるのか不安だよ。

3でOK。というより３のほうが断然いい。

>>331
>>332
ありがとうございます。

マウスでグラフ棒引いたりしたいですが、
始めたばかりでblendが必要かどうかもまだ判断できません。
出来ることならblendなしでやりたいと思います。

>>333
Blendなしですべてのことはできる。ただし、その分XAMLの知識およびゴリゴリとXAMLを打ち込む労力が必要。

全部Blendでやってる人とかいる?
前でもアプリ作ったときは結局書き方がわからないのをBlendで作って後はXAMLをゴリゴリ修正、何かのイベントに応じてコードで動的生成とかしてたんだが。

http://sildev.net/3DDemo/

やりたいことによるべさ
Flash といっても色々あるし…

Silverlightで普通にローカルファイルを
OpenFileDialogとSaveFileDialog経由で操作できるけど
これセキュリティ違反にならんのか。

直接絶対パスとかでファイルIOする場合だけ例外なるだけ？

ユーザーの指示でしかオペレーション成功せんのに
セキュリティも何もないじゃろ

ドキュメントを見れば判るが、アプリ側が好き勝手できない様な設計にもなっているしな。
あくまで、ユーザーの選択したファイルに対してのみ操作ができる構造になっている。

gsfgsfgsfgs

VS　しかないけど　シルバーライト導入する意義はありますか
WPFだったらどうなんだろう

ねえよ

UI をリッチにしたいかどうかしだいだろ。

VWDの無料版でもいいからインストールする気はあるか。
描画は若干遅くなっても、クラスプラットフォーム、
自動バージョンアップに魅力を感じるか。

この辺じゃないかなぁ。

何がしたいのかそれだけでわかるかよ(´・ω・｀)

すまん、クラスプラットフォームじゃなくてクロスプラットフォームだった。

自動バージョンアップだけでも導入する価値がありそう。
Flashなんていつまでウィルスのスープになってるんだか。

こういうのhttp://realtime-chart.info/ Silverlightでつくってみたいんだけどどうすればいいの？

>>348
SBIがSilverlightで作ってたな
http://pc.watch.impress.co.jp/docs/news/event/20090717_303174.html

http://timheuer.com/blog/archive/2009/08/21/silverlight-flash-comparison-based-on-bad-research-refuted.aspx

競合するけど… reflactorでデコンパイルできちゃうん
だよな silverlight...