19/09/21 08:37:33.05 IVz7LSkR0.net
詭弁…？
コンポジット型のディスプレーマネージメントはウインドウ型GUIを備えたマルチタスクOSに本来必須の機能なんだよ
例えばvramが1画面分しかないとするだろ、あるアプリAが何らかの画面を自分のウインドウに書いた後に、他のウインドウBがその上に移動してきたとする。その瞬間にAの表示内容は失われる。
次にBが移動したら、Bの下にあった領域はもはや何も描かれていないので、Aに対してこの領域が空いたというシグナルを送り、Aはそれに対して描画命令を再発行しないといけない（Aは即座にその要請に応える責任を負う）。
しかしAが重い処理をしていると当然レスポンスは遅れるし、そもそも描くべき内容の情報をまだ保持しているかは完全にアプリAの実装に頼っている。
このような内部処理がウインドウを動かすのみならず、サイズ変更やフォーカス変更の度に発行され、ウインドウ数が増えるとそのコールスタックは指数関数的に増大し、再描画すべき領域は矩形とは限らず複雑な形状となる。
だから昔のOSでは重い処理中のアプリウインドウを一度バックグラウンドにしたら、再度表示させるとのっぺりでブランクになってるなんてことがよくあった。
解決策はアプリ側でメモリを確保し、表示を更新する度にビットマップをそこにストアして、描画命令は単にそのビットマップから必要となる領域を切り出してやればよい。
各アプリがそんな事する必要があるなら、そもそもそれはOS/ディスプレーマネージャーの仕事では？というのがコンポジット型ディスプレーマネージメントが採用される理由。