BitmapEffect の負荷は高くない

せっかくなので BitmapEffect がどれだけ負荷が高いのか実験。
手持ちで一番巨大な 3072x2304px の画像を使って BlurBitmapEffect を掛けてみる。

2 ミリ秒…

BlurEffect にしてみる。

1 ミリ秒…

こりゃ差が全然解らないわけだわ。
この程度の BitmapEffect なら体感するような違いは無いってことなのね。
どういう使われ方を想定して BitmapEffect を無くす方向になったの?

解ったのは WPF で画像ビューアは一瞬で作れるということだけだった。
XAML に Image を配置して image1 という名前を付けたとして

private void Window_Drop(object sender, DragEventArgs e)
{
    string[] drags = e.Data.GetData(DataFormats.FileDrop) as string[];
    image1.Source = new BitmapImage(new Uri(drags[0]));
}

これだけ…後はプロパティを弄くるだけ。
せっかくだから何か作ろうか。

BitmapEffect プロパティが古い

SeeMe のソースを少し弄くって sp1 にしてから初コンパイルしたら…

「BitmapEffect プロパティが古い!」

と怒られた、なんやねんまったく。
てか俺って気がつくの遅!VS2008 を sp1 にしたのは何時や!

とにかく BitmapEffect は檄負荷だから近々無くなるので使うなということらしい。
BitmapEffect がハードウェア アクセラレーション化されたはずなんだけーがなぁ。

川西 裕幸のブログ : .NET Framework 3.5 SP1 Beta

しかたがない、更新しよう(そんな理由で…)

てゆーかオープンソースなんだから放置はマズイわな。

using System.Windows.Media.Effects;

img1.BitmapEffect = new BlurBitmapEffect();
↓
img1.Effect = new BlurEffect();

と Bitmap を取っ払って書き換えるだけでよさそうだが。
こうしないとアクセラレーションが使えないってことなのか?よく解らないけど。
負荷の違いは私の Athlon 64 x2 4200+ & AMD 690G のショボいマシンでも解らんぞ!

そういえば Drag and Drop での並べ替えをいいかげんに復活させなければ。
以前は全く見つからなかったがそろそろサンプルコードがネット上に上がっているかな?

CodeProject: Very Simple WPF Drag and Drop Sample without Win32 Calls. Free source code and programming help

CodeProject: Drag and Drop Items in a WPF ListView. Free source code and programming help

あぁ、これでなんとかなりそうだ。
ちなみに WindowsForm にあった listView1.GetItemAt みたいなメソッドは無い。
たかが ListViewItem 取得にこんな処理を自前で書けということらしい。

メソッドくらい用意してよまったく。
WPF がちっとも普及しない最大の理由はソレなんだから。

でも並べ替え自体は RemoveAt と Insert メソッドのみで簡単に終わる。
それもバインディングならもちろん元の ObservableCollection を並べ替えるだけ。
異様に簡単になったり異様に難しくなったり本当に面倒だなぁ WPF って奴は。

Spy++ で WPF

何を今頃の話。

Visual Studio Tools の Spy++ でちっとウインドウ検索していた。
これって UAC に引っかかるのよね、そんな大げさなアプリとも思えないけど。

ちっと思いついて SeeMe にファインダツールをドロップ。

えっ!WPF で作ったアプリには親ウインドも子ウインドも何も無いってこと???

意味不明の若い人へ説明すると…解説が難しいなぁコレ。
Win32 API で作ったウインドウはボタンやラベルも全部ウインドウである。
なのでメインウインドウにボタンがあったらボタンは子ウインドウということです。
ウインドウハンドルを持つモノは全部ウインドウ…ということで解るかな?

ソレが一つも無いということは全部ペンやブラシで描写しているのと同じコト。
ちなみに Y901 のコントローラボタンがそうやっているのでコレも当然ウインドウではない。

そういえば WPF は DirectX で描写していたんだっけ、これは「なるほど」という感じ。
.NET Framework が一番の親に居ると思っていたんだけど違っていた。
いったいドコまで今までと考え方を変えなければいけないのだろう?

もう一つ思いついて Explorer のリストビューにファインダツールをドロップ。

あれ?このリストビューって SysListView32 クラスってことなの???
解る人には解るとおり Win32 での「今までの ListView 」と同じっていうこと。
なのにこの描写、あぁワケワカになってきたぞ!

てっきり WPF と同じ方法で描写を実現かと思っていたが普通のウインドそのもの。
「何か」をやれば Win32 で作った ListView もこの「なめらか描写」に出来るってことみたい。
公開されなきゃどうにもならんが、なんか Vista って本当に難しい。

他人の動画プレイヤー

他人の動画プレイヤーを宣伝。
っっってォイ!マジでやる気ゼロかよ。

DMediaPlayer – Simple VLC frontend – Home

というのをネットをウロウロしていて見つけた。
驚いたことに C# 製だ、よくぞ C# でこのアレな業界に挑戦しようと思ったものだ。

技術的興味だと思うんだけどね、私はそんな勇気なんて無いから SeeMe から .NET 化したわけで。
WPF を絡めないとエンドな人は .NET な時点で興味どころか徹底的に嫌ってくれると解っているもの。
とはいえ WPF を絡めても Vista が普及してくれないと…

VLC media player – Overview のライブラリを使って再生するアプリらしい。

libvlc.dll が必要であるようだ、しかし libvlc.dll だけでは動かない。
なので VLC をインストールしているディレクトリに直接コピーして試してみる。
まぁ書くまでもなく VLC クローン、WMP コントロール貼り付けアプリと同じってことだね。

D&D 未対応…
なのに「開く」ダイアログは拡張子ごとの指定…
しかも前回の指定を記憶しないって…

Linux ならコレでもイイが Windows のユーザーって選択肢が多いから手厳しいよ…
でもこのインターフェイスは本物 VLC に違和感が消えない人の救世主になるかもしれない。
但し Vista ではボリュームバーがチカチカしてウザいぞ!

とりあえず「今後に期待」かな。

なんにせよオープンソースなので参考にはなる、メタボリックにならないことを祈るが。
C# なので Mono で…略。

こっち方面の作者はソースコードくらいは見ておいたほうがよさげ。
どいつもこいつも開店休業してんじゃネェよコノヤロウ!

そういう私も Cinema が止まっているが、そろそろ更新するか。