>>397
応用の利かないこむずかしいコードとかいらんから、もっと実例がほしい。
見た目やインタラクションがハデなアプリ書くには、XAML前提でのコード例やデザイン例の情報が乏しいし、
ビジネスアプリ書くには、VS標準搭載のコンポーネントの機能が（まだ）あまりにも貧弱すぎると思う。
それでもAJAXに全く興味がわかなかったへたれC#プログラマの俺には、SLはかなりありがたい。

あと、これはもう昔からのMSDNの悪い点だと思うのだが、（何ができるかの情報がとぼしいだけに）
何ができないのかについてはもうちょい簡単に参照できるようにしてほしい。
いちいちMSDNフォーラムとかで聞くのも探すのもめんどうだから、この板に期待してたり。

>>399
サードパーティのdllを梱包した場合でも、とたんにでかくなりますねえ。
System.Xml.Serialization.dllなんかもかなりでかいのかな？
クラスライブラリのビルド時にはすべてのクラスを梱包するアセンブリにして、
アプリケーションアセンブリのビルド時には全部internalアクセスに制限しつつ、
ILのコードから使われてないクラスを自動判定して、コンパクトなアセンブリ作れたらいいのに。
あれ？ありそうな気がしてきたｗ

>>400
XAPファイルのままダウンロードされるんじゃないんですか？
ZIP圧縮したDLLをXAPに梱包しても、サイズ変わらない気もしますが・・・。

いろいろ根本的に俺が間違えてたらすいません。

リフレクション、動的なクラスロードが無ければ簡単だけどね

>>402
Reflectionの本来の動作どおり、単にnull返してもいいし、
その型はアセンブリに入ってないって例外返してもいいのでは？
テストコード以外でどういう場合に、interfaceによるポリモーフィズムでなく、
Reflectionでなければならないのか興味ありますが。

XAPのサイズがでかくなるっていう元々の問題に対する別の方法として、
必要に応じてサーバから追加でdllをダウンロード（＆インストール）できたとしても、
LINQのdllがでかすぎるといったことの解決にはなってないだろうし。

>>400
画面やページ遷移にあわせてxapを分割して構築。
そんでもってクライアント側で遅延ロードさせたりでOKじゃね？
あとLINQを動かす部分をWCFサービスにすればいいし。

>>401
xapファイルの中に入ってるDLLの話なんですけど、
クラス名等の文字列がそのまま入っているです。

>>402
どうやってます？試しにxapの中のDLLをNanDokuにかけてみたら
変換中に飛びました。orz

>>404
後出しで申し訳ないんですけど、分割とか本気で小さくしないと周らない
ってほどではなくて、もう少し簡単に小さくしたいなぁ、くらいなんですね。
現在、生成されたxapが約100k。文字列とか余分な情報を削減して
スリム化できればなぁと。

>>404
> あとLINQを動かす部分をWCFサービスにすればいいし。
サーバ側で全データを管理する場合はいいと思いますが、
LINQ使うたびにクライアント側で処理中の中間データを
サーバに送信して結果返させるくらいなら、
素直に起動時にLINQ込みのXAPを落とすほうが良いように思う。
それとももっと違うLINQやWCFの使い方があるんでしょうか？

ローカルで生成したデータを、
ちょちょっとコネコネしたいときにもLINQ便利なんですよね。

>>403
ベンダーのライブラリにリフレクションが使われているかわからないでしょ
自分のコードだけなら努力でなんとかなるが
Dotfuscatorでも実現できるがリフレクションは除外するかインターフェイス化するかだね

>>405
Dotfuscatorの有料版で可能
値段上がったけどね

CoreCLRのサイズを抑えるために個別の機能はリンクしろって思想はある意味しょうがない
あとはアセンブリの細分化と動的読み込みとかで工夫かな

>>403
上３つ俺だけど
リフレクションで無くてはならないものを無くすのがSLの基本思想だね
データバインドは無理だけど

Silverlightは Safari4 とか Google Chrome2 で使えないの？
Silverlightは Safari4 とか Google Chrome2 で使えないの？
Silverlightは Safari4 とか Google Chrome2 で使えないの？
Silverlightは Safari4 とか Google Chrome2 で使えないの？
Silverlightは Safari4 とか Google Chrome2 で使えないの？

ブラウザにおさまらないほどのコントロール配置しても
IE8がスクロールバー有効にしてくれない
これはUserControlのプロパティで、スクロールバー出せるんでしょうか？

このソフトをWinXP SP1で起動させる方法を教えてください

インストールしたら、Flashと同じように、使っているウェブサイトを開くだけ。

>>412
http://www.bluerosegames.com/SilverlightBrassTacks/post/Viewbox-in-the-Silverlight-Toolkit.aspx
http://silverlight.net/samples/sl2/toolkitcontrolsamples/run/default.html

こことか眺めてると (Viewboxあたりら辺とか)
ブラウザのスクロールバーを操作するような用途
に向けて作られてないように思える…

http://www.codeproject.com/KB/silverlight/Scroller.aspx
なるべく枠内にまとまるようにレイアウトしてゆくみたいな…

http://mohammadabtahi.wordpress.com/2008/12/09/zoomable-user-interface-zui-in-silverlight-using-viewbox-control/

>>415
なるほど、スクロールが必要な設計にしなければよいわけですね
ありがとうございました。

>>412
下記のコードで書いたようなことじゃないよね？
ScrollViewerはTabItemの中で使ったら、期待したような動作にならなかった記憶もある。

// Silverlightの新規プロジェクト作って、Page.xamlはそのままで、Page.xaml.csを下記のように書き換える
public partial class Page : UserControl
{
ScrollViewer _mainSV = new ScrollViewer();
StackPanel _mainSP = new StackPanel();
public Page()
{
InitializeComponent();
// Page.xamlのWidth="400"とHeight="300"を消去することに相当
this.Width = this.Height = double.NaN;
// Page.xamlの<Grid x:Name="LayoutRoot">が、ScrollViewerに置き換えられる
this.Content = _mainSV;
_mainSV.Content = _mainSP;
for (int i = 0; i < 5; i++)
{
_mainSP.Children.Add(new Button()
{
Content = i.ToString(),
Width = 800,
Height = 100,
});
}
_mainSV.HorizontalScrollBarVisibility = ScrollBarVisibility.Auto;
}
}

只今、Silverlightでモーダル動作のポップアップウィンドウを実装しようと格闘中。
Macっぽく背面をすべて半透過のダークシェードで覆ってやりたいんだが・・・

Silverlightって積極的にdouble型使ってるけど、floatと比べて処理速度は
どんなもんなんだろ？誰か計った人いない？
なんとなくだけど、doubleを採用しているのは精度を高める為だけで、
速度のことは考えてないような‥。

無駄口たたいてるヒマがあったら測れよ馬鹿が

floatもdoubleも実際の演算のときは同じサイズの内部表現(CILのF型)に変換されて扱われるんじゃなかったっけ

積極的にdouble型が使われているような箇所で処理速度の影響が問題になるのかと・・・

long doubleよりもdoubleよりもshortや、64bit long longよりも32bit long/int、さらに16bit short、
さらに8bit charやビットフィールドが大好きな'80年代のアセンブラやC言語の組み込み君は
Z80でスーパーπでもやってろ！

ずいぶん昔、たぶん80287のころから、floatとdoubleの処理効率は変わらん。

float 100000個の演算とdouble 100000個の演算だと、時間的に変わってくるけどな

86系CPUはむしろdoubleの方が早いんじゃなかったっけ？
ハードウェアがdoubleで計算してるから、
float使うとむしろ型変換の分のロスがあって。

そりゃ、厳密に効率化すればDoubleのほうが速いだろうけど、
ほとんどの処理系で一緒になるでしょ。

どうして実測しないんですか？

おれ？
今温泉旅館で酒飲みながら、PDAからここ読み書きしてるから。
かわりにやっといて。

>>419
http://inomata.lolipop.jp/silverlight/mandelbrot.php
こういう目的で使いたいならfloatとdoubleの演算精度を比較してもいいが、
アプリがやることのほとんど全てが浮動小数点演算でもない限り、実行速度の差は無視できる。
まあ、そもそもそういうのが気になる人は、やっぱり自分でベンチマーク書くもんですｗ

ただSilverlightでは精度の高いSystem.Diagnostics.Stopwatchは使えなくて？、
50ミリ秒くらいの精度しかないDateTime.Nowしか使えなかった気がする。dll参照足りなかっただけかな？？
3D描画とかをやりたいなら、Silverlight3でGPUアクセラレーションが使えるようになるのを待つべきかと思う。

>>421
Silverlightアプリ上では確認してないが、
.NETでのfloatとdoubleの演算精度は定義どおり違うものだし、
実行速度にもごくわずかに差は出ることは確認済み。

>>427
いや、floatのほうが速いよ？常識だろｗ

結局は要件次第だから
性能に影響無い箇所なら使いたいほうを使え
理論だけでコードが汚いやつはアホ

仮にfloatにして処理が速くなったところで、それで浮いた実行時間は他に活用できるほどなのか？

>>426
と思ったらそういう誤解か・・・。
SSE命令にまで自動的にJITコンパイルしてくれるので、floatを毎回doubleに型変換したりとかはない。
もちろん、cosやsinの計算とかをいちいちfloatに格納して、それをまたdoubleに戻して別の演算みたいな、
明示的な型変換がコード中にたくさんあれば、単にdoubleで全部計算するよりも遅くなることはありうる。
ソースコードに対しては忠実な動作をするからね。

GUIコンポーネントのプロパティの型に出てくるようなdoubleは、当然doubleのまま使うべき。
そんなもん実行速度の差が出るわけないです。

まああれだ。結論だけ言っておくと、心配なら全部doubleで書きなされ。
実行速度の差は無視できるが、演算精度の差は無視できないから。

>>431
え、まじ？
なんでそんなことになるの？
ちょっと不思議。

ソフト業界には、「処理効率を少しでも上げるため」と言って、残業や休出してまでカリカリに
チューニングしたり、勝手に既製のライブラリまでカスタマイズして納期を遅らせるマニアな
香具師が居るけど、会社や顧客にとってはそいつに払う残業代や休出手当てと納期遅れの方が
深刻な問題なんだよな。

>>437
動画処理や3D画像描画の、いわゆるマルチメディア関連の演算はほとんどfloatの精度ですむわけだ。
だからfloat演算専用のハードウェアが乗ってて、それを実行するのがSSE命令。
http://ja.wikipedia.org/wiki/Streaming_SIMD_Extensions

>>438
わかる
それでソースが汚いと最悪だわ
そんなことよりボトルネックは他にあるだろ

>>439
Mono.SIMDでも使っとけばいいと思うよｗ

よく考えるんだ！
Silverlightの目的はネット越しのリッチなプレゼンテーションだぞ。
高度な負荷処理はWCFなどのWebサービスに投げろ。

3Dモデルを出そうとして、更にSLとMDXのハイブリッドコード考えた時、どうしようか迷ってる。
DirectX系はfloatなので、できればそれに合わせたいけど処理速度的にはSLの方がシビア。
しかし頂点のデータ量とかも考えると、ギリギリまでfloatで最後にdoubleに変換の方がいいのかな？
と思いつつも俺の無知で、実はSLは何をするにもdoubleがベストなのは常識！とかだったら嫌なので
一応、聞いてみますた。丸投げ面倒臭がりでスマソｗ

3Dの計算って1つの数値に対する計算量はそんなに多くなくて、
短い計算を大量の座標に対して行うから、キャッシュに入りやすい
floatの方が良いと思う。

>>441
そんなもの使わなくても、コンパイラとJITコンパイラが勝手にやってくれるの。
ってわかってて冗談言ってるのかｗ？
Mono.SIMDを使わなきゃいけないんだ、とか思う人が出てくるから自重するがよろし。
まあ、SLとはまったく関係ない話だが、MS.Xna.FrameworkのVectorとかと、MDXのVECTORと、
scratchの手書きのVectorとで、実行速度に差は見られなかった。これはちょっと意外だった。

>>442
もちろんその通りだが、ローカルで行うべき高負荷な処理もあるかと。
それからWCF使うにしたって、通信量とUIレスポンスが優先されるべきだと俺は思う。

>>443
あのさ、Silverlightアプリ書いたことないんじゃない？それどころかDirectXについても理解できてないぞ？
まず、Silverlight2では3Dなんてやるべきじゃない。Direct3DもXNAもOpenGLも使えんぞ？
ラスタライズアルゴリズムを自分たちで実装してる人もいるが、実用には全く耐えない。
(誤解をおそれずわかりやすく言えば、SL2ではDirect3D相当のものを自分で一から作る必要があるってことな！)
ブラウザで3DCG動くアプリ書きたいなら、GPU支援ができるWPF Browserアプリを書けばいい。
DirectXってことはWindowsプラットフォーム限定なんだろう？だからそもそもClickOnceでもいいだろう？
それから、MDXなんてものはとっくに誰も使わないものになってるぞ？
C#で3DやるならWPFでもいいが、ゲームとか本格的な3DはXNA推奨ということになっている。
動画再生とかベクターグラフィックスとか、そういうものはもちろんSilverlight2でできるわけだが、
どうしてもSilverlightでやりたいなら、Silverlight3を待て。
つうかこれ以上は板違いってもんだ。
俺の言ってることを理解するつもりがないなら、大人しくdouble使っとけ。ってかもうちょっとちゃんと勉強するべきだ。

ちょっと>>445の文章は、わかりにくいところがあると思ったから修正。

>>443
あのさ、Silverlightアプリ書いたことないんじゃない？それどころかDirectXについても理解できてないぞ？
まずSilverlight2では、Direct3DもXNAもOpenGLも使えないから、3Dなんてやるべきじゃない。
ラスタライズアルゴリズムを自分たちで実装してる人もいるが、実用には全く耐えない。
(誤解をおそれずわかりやすく言えば、SL2ではDirect3D相当のものを自分で一から作る必要があるってことな！)
DirectXってことはWindowsプラットフォーム限定なんだから、
ブラウザで3DCG動くアプリ書きたいなら、GPU支援ができるWPF Browserアプリを書けばいい。
ただしC#で3Dやるなら、MDXなんてものはとっくに誰も使わないものになっていて、
WPFで書くこともできるが、ゲームとか本格的な3DをやるならXNA推奨ということになっている。
どうしてもSilverlightで3DCG描画をやりたいなら、Silverlight3を待て。

動画再生とかベクターグラフィックスとか、そういうものはもちろんSilverlight2でできる。

昔実測したらfloatの方が遅かったんだけどなぁ・・・
今、ネットで検索してみても、
「.NET Framework は環境に応じて SSE 最適化する」
って話出てるフォーラムがあるなぁ。
昔計ったのはなんで遅くなったんだろう。

>>439
ありがとう。
どうせFPUが処理するんだから、ワードサイズと処理単位は一致しているのが
もっとも効率的と思っていたわたしは、
486DXと486SXの違いくらいしか知りませんでした。

低レベル（下層レベル）の事ばかりを案ずる人は、.NETテクノロジーが不安で不安で
仕方なく、とても安心して使えないということだな。

.NETを安心して安心して使える、って人は存在するの？