Какой смысл использовать двойную буферизацию в цепочке отображения текстового редактора?

#c #winapi

#c #winapi

Вопрос:

Хорошо, это может быть немного глупо, я не знаю, но мне было интересно, есть ли какой-либо смысл в двойной буферизации текстового редактора. Я думал о том, чтобы печатать каждый символ в обратном буфере один за другим или, может быть, слово за словом в обратный буфер, а затем отображать обновленную часть текста на экране с помощью BitBlt? Было бы ли от этого что-нибудь хорошее? Извините, если это было глупо, я отвечу на этот вопрос, если это не соответствует стандартам.

С уважением, Devjeet

Ответ №1:

Я не могу вспомнить ни одной современной ОС / оконной системы, где такой доступ к памяти или фреймовому буферу был бы практичным — или давал бы какое-либо улучшение производительности. Что касается текста, высококачественная визуализация шрифтов true-type была решена давным-давно. Большинство оконных систем (X11 / Quartz / Aero) реализуют кэширование шрифтов и используют возможности компоновки графического оборудования.

Более непосредственный ответ заключается в том, что текстовый редактор тратит большую часть своего времени на ожидание пользовательского ввода. Маловероятно, что рендеринг является узким местом. Черт возьми, я рад, что ты думаешь о производительности на этом уровне.

Ответ №2:

Это действительно зависит от того, как структурирована ваша программа, но, вообще говоря, приложениям, ориентированным на графический интерфейс пользователя (таким как ваш текстовый редактор), будет полезно использовать двойную буферизацию, чтобы избежать этих неприятных мерцаний…

Вызовите BitBlt() с помощью screen (я называю это «live») dc как можно позже.