私もGEGLはまだ勉強中です。ブラシのような機能は実装できるのですが、非破壊編集にしようとすると、ストロークの履歴を取っておいて、毎回それをレンダリングする実装になってしまいそうです。GEGLの仕組みは、画像に対する変更操作をXMLのようなGEGLノードで記録しておいて、画像が必要になったときに、その画像の部分への変更操作を実行して1枚のバッファ(GEGLBuffer)に書き出すようになっています。部分的にキャッシュしておくことも出来ますが、あくまでもそれはキャッシュなので、ストロークの履歴を全部残しておく必要があります。openCanvasのイベント記録モードみたいなものと言うのがわかりやすいたとえかもしれません。どのくらいのストローク数でどのくらいのサイズのファイルになるのか分かりませんが、消しゴムで消しまくる私としては恐ろしい限りです。それと、どうも開発MLのブラシの議論はGEGLや現在の実装をあまり気にしていないように思います。実際に実装している人たちの考え方と合っているのかどうかは自信が持てません。
> ストロークの履歴を全部残しておく必要があります コメントありがとうございます。そしてリンク先が間違っていた...orz ストロークの履歴を取るとするとそういう実装で、履歴が増えてレスポンスがとても悪くなる懸念も理解できます。> どうも開発MLのブラシの議論はGEGLや現在の実装をあまり気にしていない この辺、自分が ML の発言等追えれてないのでなんともいえませんが、聞くとかしかないのかなぁ...。
なんか、どっちかというとGEGLを統合しようとしている人たちがそれ以外の人達に（どう変わるのか）きちんと周知するのが筋のような気がするんですが、できてなさげですよね……。Brushes/input controllers changes ideaの件に関しては、Bugzillaで以前されていた話題が混ざっているので成り行き上（GEGLが考慮されてないのは）しょうがないところもありますが。
ぉぁ、周知もできてない状態だったんですかね。うーん。brush 絡みで今、どういう風にしようと巻が得ているのか不透明なのは不安ですねぇ。
まあ、GEGLはこうこう、こういうものなんだから、それをGIMPに組み込めばこうなるのは当然だろ？みたいな認識だという方が正しいかもしれません（なのでどういう実装になるのか、という話題がコアメンバーの側からはあまり出てこなかった、と推測）。あと、話の場がMLとBugzillaとIRCにバラけているのも事を分かりにくくしているような……。あっちできちんと話したから、もういいじゃないの、ということになると「そらそうでしょうけど、ちょっとね」みたいな感じです（仮にIRCでの話を周知のこととして物事が進められてしまうとなれば、自分には訳がわかりません）。> brush 絡みで今、どういう風にしようと巻が得ているのか不透明なのはどうも、GIMPの開発者コミュニティーでブラシ周りを重要視している人はごく限られているようですね（一部の人が勝手にアツくなっていて、他は華麗にスルーしているような雰囲気です）。実装している側は、コア部分を済ませてから改めて考える、みたいなノリなのでは。
> 話の場がMLとBugzillaとIRCにバラけているのも事を分かりにくくしているような そうなんですよねぇ、 ChangeLog 眺めてても「え？そんな話いつあったよ？」的な変更があって、調べると IRC でそんな話がなされているとか。> ブラシ周りを重要視している人はごく限られているよう 必要とすると人が声を上げていくしか無いとはいえ、コア部分が変更不能な状態になるのはぐんにょりですのぅ。
>どうも、GIMPの開発者コミュニティーでブラシ周りを重要視している人はごく限られているようですねみんな関心はあると思うのですが、実際にヘビーに使う人がどの程度ブラシを使うかを知らないんじゃないかと思います。１回何かを描くときに、全部のブラシデータの履歴を取ってみたりすると説得力があるのかもしれません。
> 説得力 やっぱり知らない or わからない人には実例を見せるしか無いですからねぇ。ふむふむ...。
Painterで5分くらい適当に描きなぐったのを記録したスクリプトをプレーンテキストに書き出してみたら約2.4MBでした（バイナリだと512KB）。この時点ではまだネイティブ形式の画像として保存するより軽いですが、10分〜20分描けば逆転するでしょう。ただ、Painterだと発生したイベントデータをそのまま並べて一本のストロークを表現しているようですが、GEGLの方はさすがにそうはならないでしょうから、ある程度は軽量なデータになると思います。それでも再生に時間がかかるという問題は残りますが……。
> GEGLの方はさすがにそうはならないでしょうから、ある程度は軽量なデータになると思います。 この辺がこの話のキーですね、どうしていくのがいいんですかねぇ。
yvindさんとSvenさんのポストを見る限りでは、あとで編集できるようにするために全部のイベント(座標とタブレットのプレッシャー、傾きなど)を記録しておく予定だそうです。キャッシュの作り次第では再描画はそれほど起こらないような気がします。どのキャッシュを使うのかを探す処理に時間がかかりそうですが…
> 全部のイベント なんというそのまんま...(あぁいや悪い意味ではなく。 キャッシュの作り方がほんとキモですよねぇ、当たり前ですが...。
全部の種類、の全部ならわかりますが、全部の数、の全部だったら、やっぱりイカレてるなあ（苦笑データが増えるだけでなくて、編集も面倒くさそうです。ちなみに、ぱっと思いついたは、パスのアンカーポイントかセグメントの属性として筆圧・傾き・速度の値を持たせる方法と、ストロークの始点から終点までの各情報の値の変化を近似したスプライン曲線（など）を生成してパス1本分の属性として添付する、とかですかね。後者はExpressionというソフトのバージョン2以降で筆圧情報を保持する手法として採用していました。
>全部の種類、の全部ならわかりますが、全部の数、の全部だったら、やっぱりイカレてるなあ（苦笑 よく読んだら"Stroke"だったので、そういうことを考えているかもしれませんね。曲線近似されるとどうしても線が変わってくるのと、GEGLのオペレーションに手を入れないと細かい挙動がいじれなくなるのとがあるので、そっちの方向には行って欲しくありませんが...
> パスのアンカーポイントかセグメントの属性として筆圧・傾き・速度の値を持たせる方法 自分はイメージとしては、 MagicTracer ( http://mt.azimech.net/ ) のような(内部処理はわからないですが)ものになるのかなぁと思ったりしました。インターフェースを見る限り、こちらも筆圧等の情報をアンカーポイントごとに持っていそうなので。 > GEGLのオペレーションに手を入れないと 自分のイメージが合っているなら GEGL のオペレーションとして実装されるような気がしています。 手を入れやすいような形式になってくれればいいんですが...、うむむむ。
>MagicTracerリンク先の画像をみると太さ記号はパスのアンカーポイントとは別の位置・数になっていますね。どちらかというと前回述べたうちの後者のほうが近いかもしれません。余談ですがExpressionの3.3betaはMicrosoftのサイトで無償配布されています（最新版は有償製品だが別物に近い）。http://www.microsoft.com/expression/expression-design/CreatureHouse.aspx?key=download# Live IDを要求されない直リンクもあったような気がしますが、一応伏せておきますベクター系のソフトですがいろいろ考えさせられるものがあるかと思います。
> 後者のほう あぅ、そうですね、読み違えてましたorz> Expressionの3.3beta ぉぉ、かの Creature House 版ですね。名前と評判だけは聞いたことがー。