今時X_clientとX_serverを分ける必要あるだろうか？

**名無しさん＠お腹いっぱい。** · 05/03/13 21:45:09

俺は無いと思う。
そんな機能をつけるよりもより軽く、より高速な物として欲しい。

**名無しさん＠お腹いっぱい。** · 05/03/15 22:46:07

>>72
だってそうじゃない？
このタイトルではもう無理だし、でも折角スレあるんだし、
人も結構いるんだし、何かの議論の場となるならそっちの方がいいじゃない。

**名無しさん＠お腹いっぱい。** · 05/03/15 22:49:12

>>68
> 誰かが、このスレの内容を不要論の方にコピペするなら、
> このスレは要らん気が…
する気はない.

つか, このペースで続けば, 今の X の問題点を洗い出
すには, ちょうどいい話の流れになってると思うが?

手頃に何も考えてないアフォが何人か混じってるみたい
だし..

**名無しさん＠お腹いっぱい。** · 05/03/15 22:59:43

og(ry

**16=40=49=54** · 05/03/15 23:29:05

うひ、なんかえらい叩かれてるな(w

>>54 の書き方も悪いけどクラサバ自体を無くせなんてことは
言ってないんだよね。スレタイにもあるように、「X のクラサバ」を
無くすって考え方もあるよね、将来鬼描画するならば。
って言ってるだけで。

要するに >>56 の

>テクスチャの話もgimpの話も、現在のXのままでも、ローカルで
>走らせれば解決する話にすぎなくて、クライアント・サーバー
>モデルを捨てる必要があるという理由になってないじゃん。

って話。ローカルで走らせることで解決する話なら、 X の
クラサバモデル無くてもいいじゃん? ってコト。

# 念のため、パフォーマンスを求める場合だよ。
# DRI レベルの話じゃない。今更 2D なんて、どーでもいいっしょ。
# あと今の X から無くせって言ってるわけでもない。
# 現に今も飛ばしたウィンドウから書き込んでるし。

**16=40=49=54=76** · 05/03/15 23:29:50

すまん、しつこいね。これ最後。

でまぁ、色々と考えてみたんだけど、描画タイミングが通常の X アプリ
程度なら実はクラサバでもイケるかもって気はしてきた。
ディスプレイリストもテクスチャもサーバ側に乗るだろうし。
ただ、遅いネットワーク経由の今の X でデカいイメージを扱うのと
似たような感覚なので、サーバからリソース消えたらえらいペナルティ
喰らうけど。(と、妄想拡張サーバの仕様を勝手に持ち出してみる)

# GPU だけじゃなく CPU プログラムもサーバに転送できれば毎フレーム描画も
# 可能だよね。って、それって結局ローカルで動かしてるだけじゃん。みたいにならん?

**名無しさん＠お腹いっぱい。** · 05/03/15 23:38:31

>>76
> って話。ローカルで走らせることで解決する話なら、 X の
> クラサバモデル無くてもいいじゃん? ってコト。

おまえ何言ってるか自分でわかってる?
さんざっぱら, extension を適当に定義すれば...
って, みんなが言ってるのに.

> # DRI レベルの話じゃない。今更 2D なんて、どーでもいいっしょ。

へ? DRI って GL を高速描画するために考えられた
メカニズムだったはずなんだが.

**名無しさん＠お腹いっぱい。** · 05/03/15 23:39:13

>>76
DRIは2Dでは使っていないのだが、何か根本的な部分で勘違いしていないか?

**名無しさん＠お腹いっぱい。** · 05/03/15 23:41:38

>Xで動くアプリは結構手が入ってるけど
アプリに手なんか余り入ってないと思うのは僕だけ？

**名無しさん＠お腹いっぱい。** · 05/03/15 23:43:28

> って話。ローカルで走らせることで解決する話なら、 X の
> クラサバモデル無くてもいいじゃん? ってコト。

アホ？
ローカルで走らせると困る応用があることは、このスレでも
出てるでしょ。

・クライアントサーバーモデルを保ったまま、ローカルで走らせる
　→ gimp も OK。リモートから使いたい場合も OK。
・クライアントサーバーモデルをやめる。
　→ gimp は OK。リモートから使いたい場合は駄目駄目。

どちらがいいかなんて、自明だろ。

> # 念のため、パフォーマンスを求める場合だよ。

そういう場合でも、ちゃんとボトルネックがどこにあるか計測して
からやるのが当然だろ。単なる思いつきでクラサバやめればぁ？
なんて言ってるのは、エンジニアリング以前。

**16=40=49=54=76=77** · 05/03/15 23:50:36

スマソ、 DRI に関してはミスった。

firefox とか gimp の話題にからまってたから矩形転送回りかと思ったのよ。
これは思い込みもあったし。

はずかすぃ。。。

# 顔真っ赤だよ(w

**名無しさん＠お腹いっぱい。** · 05/03/15 23:51:11

>>76-81
自演？

**名無しさん＠お腹いっぱい。** · 05/03/15 23:53:49

>>83
ヴァ～レ～タ～カ～

**16=40=49=54=76=77=82** · 05/03/15 23:54:39

>>81

>・クライアントサーバーモデルを保ったまま、ローカルで走らせる
>　→ gimp も OK。リモートから使いたい場合も OK。
>・クライアントサーバーモデルをやめる。
>　→ gimp は OK。リモートから使いたい場合は駄目駄目。

それはわかってるのよ。 X のクラサバじゃなくて他の方法もあるでしょ。
って話をしてるつもりなんだけど。

この場合ファイル共有の方があきらかに効率良いでしょ。

# もちろん、ファイル共有だけじゃ済まないケースもあるけど。

**名無しさん＠お腹いっぱい。** · 05/03/15 23:56:58

> この場合ファイル共有の方があきらかに効率良いでしょ。

で、何が言いたいの？ファイル共有を使いたければ使えば
いいじゃん。その場合、ウィンドウシステムは現在のままで
何も変える必要がないことになるが。

矩形転送なら DRI じゃなくて MIT-SHM エクステンション。
gimp あたりなら、既にこれは使ってる気がする。
それに、firefox はそういう問題じゃないだろ、明らかに。

とにかく実際になにが起きているのか計測せずに、勝手に
妄想しているだけでは無意味。

**名無しさん＠お腹いっぱい。** · 05/03/16 00:01:58

クライアント/サーバーモデルは兎も角、
ATOMとPROPERTYに関しては別鯖立てても良くない？

**名無しさん＠お腹いっぱい。** · 05/03/16 00:06:38

なんでそうする必要があるの？
今なんとかした方がいいのは、いまどきのGPUに対応した
描画プリミティブの改善と、ローカルな場合に、テクスチャ
などの資源を効率良くGPUに送り込む方法(どちらも、
Xのエクステンションの追加で行うべき話) であって、ATOM
やPROPERTYなんて今のままでも全然問題ないと思うけど。

**3 == 5 == 7 == 10 なんだけど** · 05/03/16 00:07:14

>>82
> firefox とか gimp の話題にからまってたから矩形転送回りかと思ったのよ。
> これは思い込みもあったし。

今時、それなりのネットワーク帯域と高速なレンダリング
パイプ持ってれば、2D でしこしこ書くより 3D で書いて、
ビューモデルを 2D にマップした方が早いって知ってる？

**3 == 5 == 7 == 10 なんだけど** · 05/03/16 00:10:14

ごめん。
89> マップした方が早いって知ってる？
「速い」だよね。

**名無しさん＠お腹いっぱい。** · 05/03/16 00:30:29

>>88
で, 元の X protocol は extension の決定と, 描画領域を含むウィ
ンドーの map/unmap だけを行うと...
それはそれで気持がいいな.

**16=40=49=54=76=77=82=85** · 05/03/16 00:41:33

>>89
あぁ、ネットワークで帯域足りる環境もあるのかぁ。

いや、実はこの一連の妄想って毎フレーム更新するくらいの GL 環境を
考えてたのよ。で、問題になるのがネットワーク経由のウィンドウ
飛ばしかな、と。
(鯖の GPU/CPU のアーキテクチャは? とか、そんなデータ送れんの? とか、
結局鯖にプログラム送ったらローカルと変わらんじゃん? とか。)

でも、よくよく考えてみれば X みたいにウィンドウ飛ばさなくても
昔からある portforward なりファイル共有なりで、実は大半の目的は
達成できるんじゃないかって思ったわけ。

なら、 X のクラサバ捨ててもいいんじゃん? って思ったって感じ。

>>86

ってことを言いたかったんだけど、まぁ、前提が妄想だからなぁ。
もっと >>49 で妄想を強調すべきだったね。すまんね。

**名無しさん＠お腹いっぱい。** · 05/03/16 00:48:12

>>92
> でも、よくよく考えてみれば X みたいにウィンドウ飛ばさなくても

ウィンドーは飛んでないぞ.
飛んでるのはウィンドーの管理リクエストと該当
ウィンドーに対する描画リクエスト.
まぁ, 実際には入力その他のイベントも飛ぶけどね.

**名無しさん＠お腹いっぱい。** · 05/03/16 13:22:16

>>70
今重複スレが多いことが
重複スレを増やしていいことの理由にはならんよ。

**名無しさん＠お腹いっぱい。** · 05/03/16 15:30:27

>>94
理由にならなかったら経済戦略の色々な技術が根拠を失うけどな。
気持ちは分かるし94を否定するつもりは無いが、
その情念は今は危険だ。

**名無しさん＠お腹いっぱい。** · 05/03/16 15:33:34

>>70
全部削除依頼出していいよ。

**名無しさん＠お腹いっぱい。** · 05/03/16 15:34:17

# rm -fr http://www.2ch.net/*

**名無しさん＠お腹いっぱい。** · 05/03/16 23:00:12

そのスレをすてるなんてとんでもない！

**名無しさん＠お腹いっぱい。** · 05/03/17 00:09:21

>>94,96
ウソスレと何とかはウニ板の花!!!
つか, クソじゃないスレが何割あるよ?

**名無しさん＠お腹いっぱい。** · 05/03/17 00:27:57

とりあえず 100 でも取ってみるか。

**名無しさん＠お腹いっぱい。** · 05/03/17 01:21:04

コンピュータやプログラムについてあんまり理解がないのだが、前々から
「なんでLinux(UNIX)のGUIプログラムは動作がWinに比べてモッサリしてるんだろ？」と
疑問を持ちつづけてきた。

自身の経験やこのスレも含めた諸々の情報を解釈するに、

・ハードのドライバがWinに比べて最適化されていないのは確かだが、それが上記モッサリの
　原因とはなりえない。　なぜなら、2D描画ごときタスクはハードウェアにとってさしたる負担
　ではなく、またドライバの出来が体感を左右する程影響することもない。　あくまで3Dの話。

・Xは大規模で複雑なソフトウェアである。最適化によって上記モッサリを改善する余地が
　あるかもしれない。が、クライアント?サーバな仕組みがその原因ではない。　よくあるクラ
　イアントとサーバが線で繋がれた図で見ると確かにボトルネックっぽく見えるが。

・GTK+,Qt 実はこれらXの上のライブラリが最大のボトルネックじゃなかろうか。
　体感速度向上の最適化はまだ本腰を入れて取り組まれていないようだ。　今後新しい
　コンパイラ gcc4.x とセットでモッサリ解消が進むのではと楽観的に期待している。

以上、素人のチラ裏でした。

**名無しさん＠お腹いっぱい。** · 05/03/17 01:55:44

そりゃ、Python+GTKとかで書けば遅いわな。
Mozillaは大差ないじゃん。

**名無しさん＠お腹いっぱい。** · 05/03/17 01:58:46

だいたい合ってるけど、細かいこと言い出すと

> ・ハードのドライバがWinに比べて最適化されていないのは確かだが、それ
> が上記モッサリの原因とはなりえない。

もしアクセラレーションがちゃんと効いてないと、
モッサリどころか、目茶目茶遅くなる場合もあるので注意。
>>32の32bppのケースとか。

> クライアント?サーバな仕組みがその原因ではない。

3D game みたいな応用の場合、Xプロトコルの機能不足が
原因であるケースもある。ただし、これについてもクライ
アント・サーバな仕組みを保ったままエクステンションの追加で
問題を解決することが可能。

**名無しさん＠お腹いっぱい。** · 05/03/17 11:45:46

サーバ・クライアント間の回線が細い場合はどうよ？
イベントが体感できるほど遅く届くとか、イメージの
転送に時間がかかるとか。

**名無しさん＠お腹いっぱい。** · 05/03/17 12:22:20

>>101

GTK の開発者間で最適化しようという流れになっているの ?
ボランティアベースのプロジェクトって, こういう曖昧な要求に対しては
動きが鈍いと思うんだけど.
あと, コンパイラを gcc 4.x にかえたからといって, 劇的に速くなるとは思えない.
結局, 3 年後も今と同じだと思う.

**名無しさん＠お腹いっぱい。** · 05/03/17 12:27:55

>>104
今話題になってるのは、そういう遅くなって当たり前の
話じゃなくて、ローカルで本来速いはずの動作がなぜか
遅いって話では？

**名無しさん＠お腹いっぱい。** · 05/03/17 14:02:56

そもそも windows の toolkit と比較するのが間違ってるんじゃないの。

**名無しさん＠お腹いっぱい。** · 05/03/17 17:00:53

そもそもtoolkitをウィンドウシステムと分離したのがX Window Systemの敗因

「それがいい」と言っている人がいる限り、UNIXは一般人の間には普及
しないんだろうなあ。

**名無しさん＠お腹いっぱい。** · 05/03/17 17:14:14

敗因って何に負けたの？

**名無しさん＠お腹いっぱい。** · 05/03/17 17:17:35

自民党にでも負けたんじゃない？

**名無しさん＠お腹いっぱい。** · 05/03/17 20:40:06

>>108
> toolkitをウィンドウシステムと分離
って, どうゆう意味よ?

**名無しさん＠お腹いっぱい。** · 05/03/17 21:01:33

toolkit 層をきちんと分離すると、効率が落ちるとでも
思ってるんじゃないの？阿呆すぎる。

**名無しさん＠お腹いっぱい。** · 05/03/17 21:23:15

遅いのを全てドライバのせい、メーカーのせいにしてても何も前に進みませんよ。

**名無しさん＠お腹いっぱい。** · 05/03/17 21:29:09

>>113
してないじゃん.
nVidia のドライバだって, Windows に比べると遅いし,
DRI の仕様にも問題があるって書いてあるじゃん.

**名無しさん＠お腹いっぱい。** · 05/03/17 21:31:02

>>114
それをドライバのせいって言うんじゃないの？

**名無しさん＠お腹いっぱい。** · 05/03/17 21:35:44

>>115
DRI の仕様がちゃんと最近のレンダリングパイプに
対応できていれば, nVidia だってもっと速いドラ
イバが作れてるはずだから, DRI の仕様を見直す必
要があるのでは?
と言う意味で, 言ってるんだが...
だれも, ドライバのせいにしてないと思うぞ.

# メーカが GPU の仕様を公開してくれないのは,
# また, 別の話.

**名無しさん＠お腹いっぱい。** · 05/03/17 21:41:05

DRIってショボいんだね・・・
Xの根幹技術がこんなんでよく
”UNIXなら古いPCでもサクサク動く”←UNIX好きの奴が良く言う台詞
なんて言葉が出てくるものだよ。

**名無しさん＠お腹いっぱい。** · 05/03/17 21:44:58

>>117
> ”UNIXなら古いPCでもサクサク動く”←UNIX好きの奴が良く言う台詞

それは、また別の文脈だろう…
少なくとも、スクリプト書いて処理できるレベルなら、 Unix の方が
効率よく処理できるのは事実なんだから。

**名無しさん＠お腹いっぱい。** · 05/03/17 21:50:49

> ”UNIXなら古いPCでもサクサク動く”←UNIX好きの奴が良く言う台詞

はつみみです。

**名無しさん＠お腹いっぱい。** · 05/03/17 22:30:52

> DRIってショボいんだね・・・
> Xの根幹技術がこんなんでよく

えええ、DRIをXの根幹技術だと思ってる君は何者？
% xdpyinfo | grep DRI
XFree86-DRI
名前を見るだけで分かる通り、最近になってXFree86
projectで付け加えたものですが、なにか？

あと、DRIがショボいんじゃなくて、GPUの利用方法が
最近変わりつつある(GPUがプログラマブルデバイスと
化してきている)ので、それに応じた別のエクステンション
が必要だってことなんだが。
これに関しては、金かけまくっているWindowsの方も、
まだ変化の途中に過ぎないだろ。

**名無しさん＠お腹いっぱい。** · 05/03/17 22:39:57

>>120

> あと、DRIがショボいんじゃなくて、GPUの利用方法が
> 最近変わりつつある(GPUがプログラマブルデバイスと
> 化してきている)ので、それに応じた別のエクステンション

うーん、わかんねーな。Ｘでフラグメントプログラム書くってこと？

**名無しさん＠お腹いっぱい。** · 05/03/17 23:02:38

うん、そゆこと。DRI の仕組みで書けたっけ？

**名無しさん＠お腹いっぱい。** · 05/03/17 23:20:21

しかし、これが firefox や gimp とは関係ないのは明白だな。
Win用の firefox や gimp だって、フラグメントプログラム
は使ってないのは間違いないからな。
それどころか DirectX 依存の処理だってやってないんじゃ
ないか。GDI の範囲内だけだろう。

結論: アプリかツールキットを直せ

**名無しさん＠お腹いっぱい。** · 05/03/17 23:29:16

gimp が遅いって人は
同じマシンの gimp for win ときちんと比較して行ってるの？

**名無しさん＠お腹いっぱい。** · 05/03/18 00:03:46

DiaとかSodipodiのWin版なら使ったことあるけど、普通に遅かったよ。

**名無しさん＠お腹いっぱい。** · 05/03/18 00:16:00

>>122

書けないことはないと思うが、フラグメントプログラムで
何をしたいのかが聞きたい。

**名無しさん＠お腹いっぱい。** · 05/03/18 00:24:10

Qt/KDEは最適化を意識する動きがあるからちょっと期待できる。

**名無しさん＠お腹いっぱい。** · 05/03/18 01:06:32

ここまでにもちらほら出てきてて気になってたんだけど,
X が遅いのは GPU をちゃんと使えてないからなの ?
>>123 でも出てるけど, gimp とか firefox とかでは関係ないのでは ?

それよりも, OpenOffice の GUI ってもっさりしてない ?

**名無しさん＠お腹いっぱい。** · 05/03/18 01:22:55

>>126
ﾁｮｰﾊﾞﾘﾊﾞﾘな3Dゲームとか?

**名無しさん＠お腹いっぱい。** · 05/03/18 01:26:32

>>128
> X が遅いのは GPU をちゃんと使えてないからなの ?
そこの切り分けすら、スレの中ではまだ何もやっていない。

> gimp とか firefox とかでは関係ないのでは ?
これに関しては、作ってる側が window system (バック
エンドは何でもいい)の、責任にしてしまってる部分が
多々あった(最近の状況は知らない)ので、いっしょくたに
話されている部分もある、と思う。

**名無しさん＠お腹いっぱい。** · 05/03/18 01:27:12

> X が遅いのは GPU をちゃんと使えてないからなの ?

ちゃんと原因を追求しないで答を求めるのは意味ないだろ。
遅いにもいろいろあるから、原因だって複数あるだろ。
>>32のX24なんかは、ドライバが、アクセラレーション機能を
ちゃんと使えてないってだけの理由なんだし。

> それよりも, OpenOffice の GUI ってもっさりしてない ?

OpenOffice は想像を絶する巨大プログラムなので、ぜんぜん
最適化されてない。だいたいソースを展開するだけでディスク
を1GB、コンパイルするだけで4GBも必要とする単一アプリケー
ションなんて俺は初めて見たよ。

**名無しさん＠お腹いっぱい。** · 05/03/18 01:35:20

ソースが1GBもあるの？すげえ。

**名無しさん＠お腹いっぱい。** · 05/03/18 01:38:15

>>1 が何考えて立てたかわからんけど、
徐々に良スレ化してないか、このスレ？

**名無しさん＠お腹いっぱい。** · 05/03/18 01:45:32

比較的詳しい人をあおって雑談に参加させ、
読んでて飽きない程度の雑談を展開するレベルのネタスレだと思う。

**名無しさん＠お腹いっぱい。** · 05/03/18 01:49:24

>>134
それでもいいんだけどね.
少なくとも, X の現状のスナップショットにはなってるでしょ?

**名無しさん＠お腹いっぱい。** · 05/03/18 01:52:20

>>133-134
（　ﾟдﾟ） …

**名無しさん＠お腹いっぱい。** · 05/03/18 10:11:33

レンダリングパイプって言葉を使ってるやつが
ひっかきまわしてるだけだろ。

**名無しさん＠お腹いっぱい。** · 05/03/18 12:40:33

X、遅いか？

**名無しさん＠お腹いっぱい。** · 05/03/18 13:02:07

フォントをサーバ側とクライアント側のどっちが描画しているのかややこしくて、
freetype バックエンド(xttパッチ入り)と xft の違いが良くよからんです。

freetype バックエンドを使った場合は、Xサーバ側のフォントが使われて
xft を使った場合は、Xクライアント側のフォントが使われる

という解釈は正しいでつか？

漏れとしてはXクライアント側のフォントじゃなくて、Xサーバ側のフォントを常に
使わせるようにしたいんだけど、これは xorg.conf とかでなんとかなるもの？
それともどっちのフォントを使うかはアプリケーション依存？

fonts.dirだったり、fonts.confだったり、設定ファイルがとにかくややこしすぎるよ。
歴史的経緯はどうでもいいから、なんとか統一できない？

**名無しさん＠お腹いっぱい。** · 05/03/18 13:34:05

スレ違い

**名無しさん＠お腹いっぱい。** · 05/03/18 14:49:07

体感速度を改善する、といったユーザビリティ関連のタスクはドキュメント整備と同様に
オープンソースでは二の次として後回しされ、まだうまく機能していない。

これを実現するためには、
■体感速度に不満を感じるケースを広くユーザから集め
■その原因を特定し
■根本的対策を施す。必要なら組織横断的にタスクフォースで。
といった枠組みが不可欠と思われる。

KDE,GNOMEなど統合デスクトップ環境ならすでにbugzillaがある程度上記機能を包括しているが
充分な力が入っているとは言い難い。
能力と権限を備えた特殊部隊が必要だろう。MSやAppleのように。

**名無しさん＠お腹いっぱい。** · 05/03/18 18:19:30

>必要なら組織横断的に
って下手したら著作権法違反で逮捕されるじゃん。
犯罪者と手を組む人なんているの？

**名無しさん＠お腹いっぱい。** · 05/03/18 18:24:14

>>142
おまえわかってないだろ。

**名無しさん＠お腹いっぱい。** · 05/03/19 07:19:39

一つ聞くけど、
このスレってLinux用のP2P作りたがってる人とか常駐してたよね？
あとMSの人とか。

**名無しさん＠お腹いっぱい。** · 05/03/19 11:08:06

>>144
> 一つ聞くけど、
いいですよ。

> このスレってLinux用のP2P作りたがってる人とか常駐してたよね？
いいえ。

> あとMSの人とか。
いいえ。

**名無しさん＠お腹いっぱい。** · 05/03/20 00:08:39

勘違いなのか。それは申し訳無い。

**名無しさん＠お腹いっぱい。** · 05/03/20 00:40:47

分ける必要はないが、別に分けても困らない。
ちなみに俺はピッチリ横分けだ。

**名無しさん＠お腹いっぱい。** · 2005/03/31(木) 16:42:19

ModularizationProposal - X.Org
http://wiki.x.org/wiki/ModularizationProposal

**名無しさん＠お腹いっぱい。** · 2005/03/31(木) 21:07:09

丁度こんなスレまってたんだよ．．．

先日セレ300Mhzでメモリ64MBでHDD6GBのシャープのPJ2っていう
SVGAモバイルノート購入したんですけども、FreeBSDインスコしたら
重くて使い物にならんのですよ。

ですんで、メインPCに対するモバイルXサーバにしようともくろんでる
のですが、どうやったらメインPCの方に接続できるのかわからんのです。

どっかにそういう使い方しているようなことについて書かれたHPとかないすか?

**名無しさん＠お腹いっぱい。** · 2005/03/31(木) 21:10:57

以下で分からないのなら、くだ質に行くのがおすすめ。

[モバイルXサーバ]
xhost +メインPC
[メインPC]
export DISPLAY=モバイルXサーバ:0

xdmを使っている場合はこの限りにあらず。

**名無しさん＠お腹いっぱい。** · 2005/03/31(木) 23:24:31

っつーかいい加減スクラッチしろよ

**名無しさん＠お腹いっぱい。** · 皇紀2665/04/01(金) 11:00:23

　　ﾀﾞ､ﾀﾞ､ﾀﾞﾘｰﾀﾞﾘ ♪
　　　　　　＼ｸｾｯ、ﾏﾏﾝ、ﾄﾞ､ﾏﾝﾄﾞｸｾｯ／
　　　　　　　♪　('A`) ♪
　　　　　　　＿ノ　 )>＿ｷｭｯｷｭ♪
　　　　　　／.◎。／◎｡／|
　　　　　　|￣￣￣￣￣|