FreeBASIC Screenlock

FreeBASIC の、全ての描画ライブラリ関数は、フレーム・バッファに描きます。そして、自動ルーチンが、それぞれの描画のときに、フレーム・バッファの内容を、実際の画面メモリにコピーします。
ユーザ・プログラムが、たくさんの描画をするとき、自動リフレッシュは、かなりの量の時間をとるかもしれません。

Screenlock 関数が自動リフレッシュをロックするので、スクリーン・リフレッシュを実行する前に、いくつかの描画操作をするかもしれません。それで、実行速度を上げて、ユーザが部分的な結果を見ることがないようにします。

フレーム・バッファ・メモリは、画面がロックされている間、ポインタ(SCREENPTR 参考)を使ってだけ、自由にアクセスされます。
原始的な描画命令文 (LINE (描画), PSet , DRAW STRING, ... ) は、いつでも使うことができます。

画面リフレッシュは、それを再開する SCREENUNLOCK 命令文の使用まで、ロックされたままになっています。

Screenlock の呼び出しは、 対応する SCREENUNLOCK の呼び出しと、対にする必要があります。
描画ドライバーは、カウンタを使って、Screenlock が何回呼ばれたかについて、経過を追います。
Screenlock を最初に呼び出したときだけ、実際にロック作業を実行します。
Screenlock へのその後の呼び出しは、カウンタを増加するだけです。
逆に、SCREENUNLOCK は、ロック・カウンタがゼロになるまでは、カウンタを減少させるだけです。ロック・カウンタがゼロになったとき、実際のアンロック操作が実行されます。
Screen (描画) や SCREENRES を使うと、画面モードを変更する前に、すべてのロックが解除されて、ロック・カウンタはゼロに戻されます。

ページのロック時間は、できるだけ短くすることを、強く勧めます。
画面がロックされている間は、描画画面だけが現れるはずであり、入力/出力 や、待ちは、避けられます。
また、Win32 と Linux では、画面は、OS がイベントを処理する糸(スレッド)を、止めることによって、ロックされます。
画面が、長い間ロックされ続けると、イベント待ち行列があふれ(オーバーフローし)て、システムは、不安定になるかもしれません。
引き起こされたロック時間があまりに長くなるとき、 ダブル・バファリング（Screencopy で）の方法を使うことが望ましいです。

自動リフレッシュは、フレーム・バッファの、目に見えるページだけに起こります。
Screenlock は、目に見えるもの以外のページに描くとき、効き目がありません。