Почему DoubleBuffered отключен по умолчанию?

Это - действительно деталь реализации. Когда-то давно я думал, что это могли быть нулевые байты или тысяча байтов, что это не имеет никакого влияния на спецификацию языка. Но, после рассмотрения стандарта (разделяют 5.3.3), sizeof определяется как всегда возврат того или больше, несмотря ни на что.

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

Это требуется для, среди прочего, позволяя Вам обработать массивы объектов и указателей на них. Если бы Вашим элементам позволили быть нулевого размера тогда &(array[0]), то было бы идентично &(array[42]), который собирается вызвать все виды опустошения к Вашим циклам обработки.

причина, почему это не может быть машинное слово, состоит в том, что нет никаких элементов в нем, которые на самом деле требуют, чтобы это было выровненное на границе слова (такой как целое число). Например, если Вы помещаете char x; int y; внутренняя часть класс, мой GCC синхронизирует его на уровне восьми байтов (так как второй интервал должен быть выровненный в той реализации).

25
задан Wouter van Nifterick 11 September 2009 в 02:07
поделиться

3 ответа

Как вы, вероятно, знаете, двойной буфер обычно включает создание закадрового буфера памяти того же размера, что и визуальный компонент. Запись / рисование выполняется в этом буфере, и по завершении весь буфер «заменяется местами», так что теперь он отображается на визуальном компоненте.

(Примечание: «подкачка» может состоять из простого изменения адреса, на который указывает указатель, или может фактически включать в себя копирование части памяти, например, с использованием BitBlt, memcpy и т. Д.)

Следовательно, для поддержки выделяется разумный объем памяти этот процесс для каждого компонента, для которого он включен. Если в вашем приложении много окон и / или компонентов, будет выделен немалый объем памяти. Если вам не нужны плавные визуальные обновления / прокрутка, зачем тратить эту память?

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

Если ручная установка DoubleBuffered на true является для вас проблемой, вы всегда можете создать свой собственный пользовательский элемент управления / компонент который наследуется от встроенного элемента управления и устанавливает для DoubleBuffered (и других свойств) требуемые значения по умолчанию.

и устанавливает для DoubleBuffered (и других свойств) требуемые значения по умолчанию.

и устанавливает для DoubleBuffered (и других свойств) требуемые значения по умолчанию.

32
ответ дан 28 November 2019 в 18:07
поделиться

Следует избегать двойной буферизации, когда выполнение какого-либо удаленного рабочего стола, поскольку все растровое изображение элемента управления / формы должно быть отправлено по сети для выполнения BitBlt. см. это сообщение в блоге ...

25
ответ дан 28 November 2019 в 18:07
поделиться

В современной ОС, которая выполняет компоновку рабочего стола, двойная буферизация может фактически снизить производительность. Рендеринг в любом случае выполняется в растровое изображение за пределами экрана, поэтому использование двойной буферизации приводит к дополнительному копированию, не приносящему никакой пользы в этих системах. Поэтому, если VCL не достаточно умен, чтобы игнорировать двойную буферизацию в этом случае (не знаю, есть ли она, потребуется проверить), на самом деле может быть лучше не устанавливать ее безоговорочно.

Изменить:

Я проверил , и в Delphi 2007 и Delphi 2009 метод TWinControl.WMPaint не использует двойную буферизацию, когда DwmCompositionEnabled возвращает True . Хорошо.

13
ответ дан 28 November 2019 в 18:07
поделиться
Другие вопросы по тегам:

Похожие вопросы: