GUI端末エミュレータでカーソルのちらつきを達成するには?

GUI端末エミュレータでカーソルのちらつきを達成するには?

点滅は、特にカーソルの場合、コンピューティングの初期から一般的な慣行であった。

ただし、ターミナルエミュレータまたはシェルは、straceこれを確認するシステムコールを実行しても、どの種類のタイマー(パス)またはインターバルタイマー(パス)も登録しません。同時に、これらのプログラムはスピンロックを使用して一定時間待つことはできません。konsolebashtimer_settime()setitimer()

実際の端末は、そのコントローラが点滅脱出制御シーケンスを理解しているため、これを行うことができます。しかし、グラフィックモニターは明らかにこのようなことはできません。

それでは、これらのプログラムは、特にグラフィック環境でテキストをどのように点滅させますか? X以外のグラフィック端末でもテキストが点滅することがあります(を押すのと同じCtrl+Alt+F2)。

点滅する端末カーソルはどのように発明されましたか?この質問は、なぜこれが発明されたのか、そして実際の端末がそれをどのように実装するかについての技術的な詳細を示しています。

答え1

あなたの質問は、点滅カーソルと点滅テキストという2つの概念を混同します。

GNOMEターミナル(VTE)は長い間点滅するカーソルをサポートしており、5年前に点滅するテキストサポートを追加しました。点滅するテキストのサポートに関する3つの興味深い詳細を共有します。気に入ってほしい :)

これはあなたの質問に対する答えではなく(実際の答えは別々に投稿しました)、それは横に付けられたコメントです。


興味深いのは、テキストが正確にいつ点滅するかです。

テキストのちらつき速度はカーソルのちらつき速度に関連付ける必要がありますか、それとも別の属性でなければなりませんか?私たちは同じ速度で動き、このオプションを奪います。 IIRC はkonsole両方とも異なる周波数を使用します。

点滅するテキストを含む複数の端末が同時に点滅する必要がありますか?私たちの結論はそうです。それ以外の場合、非常に迷惑になる可能性があります(ちょっと点滅しているテキストが最初に迷惑ではなかったかのように)。テキストがオンまたはオフになるタイミングはシステムクロックに基づいています。

点滅しているカーソルは、キーを押すたびに常に完全に「オン」な状態で再起動されます。私たちはこの行動を維持する必要がありますか?結論は「はい、この行動を維持してください」です。

カーソルとテキストが同時に点滅する必要がありますか?同時に、すべてを持つことはできず、可能な基準の1つを軽減する必要があることを簡単に知ることができることを願っています。いいえ、両方は同期されません。

これがこれらの質問に答えることができる唯一の方法ではありませんが、私たちが最も合理的であると考えた方法です。


\e[5m\e[25m点滅テキストサポートを実装するには、対応するエスケープシーケンスまたはエスケープシーケンスが表示されるタイミングは重要ではありません。スクロールバーはデフォルト以外の場所に設定され、スクロールバックの内容を表示できます。明らかに、各セルに対してセルがフラッシュされているかどうかなど、すべての色と装飾のプロパティを追跡する必要があります。重要なのは、そのようなセルが現在のビューポート内に存在するかどうかです。

VTEでは、全画面を再描画する必要がある場合もありますが、画面の一部(コンテンツが変更される部分)のみが再描画される場合もあります。

基準の1つは、ビューポートに点滅するテキストがない場合(ほとんどの場合)何もせず(または悪い場合:同じコンテンツを再描画せずに)、約0.6秒ごとに端末を目覚めさせてはいけません。これは、省エネ、ノートパソコンのバッテリ寿命を延ばすなどのために重要です。

私は長い間周期的なタイマーについて考えてきました。点滅するテキストが描画されるたびに、点滅状態が変わるたびに始まる周期的なタイマーが始まる。その後、画面を再描画します(可能であれば関連部分のみ)。

しかし、この定期的なタイマーをいつ停止する必要があるのか​​、どうすればわかりますか?長い間、私は明確で簡単な答えを見つけることができませんでした。

それからペニーが落ちた。周期的なタイマーについては考えないでください。現在の画面に点滅しているテキストの状態を変更する必要があるため、ワンタイムタイマーのみをインストールしてください。ビューポートにまだ点滅しているテキストがある場合、再描画は次のワンタイムタイマーをインストールし、コンテンツが点滅しなくなるまで続きます。この堅牢で非常に単純なソリューションのコストは、誰も気にしない最後の追加の不要な再描画です(点滅しているテキストがあるpoll()状態でこれらの呼び出しをデバッグ、追跡、および調査しない限り)。


多くの人はアプリでちらつくテキストを見たいと思っています。多くの人がこの機能を嫌い、ちらつくテキストを見たくありません。おそらく、集中した端末でのみカーソルが点滅するのと同様に、多くの人は集中した端末でのみ点滅するテキストを見たいと思うでしょう。

しかし、GNOME端末は4番目の珍しいオプションも提供します。つまり、焦点が合っていないウィンドウでのみテキストを点滅させます。私が思いついた思考プロセスは次のとおりです。目を点滅させることは、本当に予想外の衝撃的なものに注意を引くために使用されるようです。集中している間、これは不要で注意が気になることがあります(たとえば、警告を受けた問題を解決しようとする場合)。しかし、周囲の視力は、静的警告を一度だけ印刷するよりも、ちらつきなどの変化に敏感です。

私たちはソフトウェアで分析を実行せず、(怒りを引き起こす可能性がある)統計を送信しないため、これら4つのオプションの人気に関する情報はありません。特に、誰かがこの「注意を払っていないときだけ」オプションが役に立つと思っている場合は、はるかにそうです。 。

答え2

調べたところstracegnome-terminal-serverこれがGNOME端末の実際のプロセスです。

アイドル状態のときにカーソルだけが点滅している場合、これはカーネルpoll(..., 598)呼び出しまたは同様のカーネル呼び出しに常駐します。つまり、poll()タイムアウトは0.6秒よりわずかに短いです。 (GNOME全体の点滅期間のデフォルト値は1.2秒であるため、各オンまたはオフの状態は0.6秒です。これは、カーソル領域を再描画するなど、前回の実際の作業量と同じくらい短くなります。)

これはpoll()、指定されたファイル記述子の1つにアクティビティがあるか、タイマーが期限切れになるか、シグナルが到着するのを待ちます。

これはpoll()「手動で」実装されておらず、むしろVTE(GNOME端末と他の端末の背後にある端末エミュレーションウィジェット)がGLibのメインループにイベントハンドラを登録し、GLibが実際の基本実装を担当します。どの方法を使用するかを決定することはGLibに依存します。たとえばselect、またはを使用することができます、epollまたはtimerfdおそらく他のオプションがあります。

私はそれを行うときにほぼ同じ呼び出しを見ており、他poll()のほとんどの端末エミュレータも同様のことをしていると思われます。stracekonsole

端末(Bashなど)で実行されるプログラムは、フラッシュに必要な適切なエスケープコードのみを出力し、実際のフラッシュの実行には参加しません。エスケープ文字を印刷したプログラムはずっと前に消えましたが、点滅しているテキストはまだ端末に表示されます。

関連情報