Изменение размера Bitmap

@T2skler · Регистрация: 16.05.2012

Студворк — интернет-сервис помощи студентам

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

@DefineFalseTrue · 12.10.2012, 11:56

Не замечал особых проблем с производительностью при изменении размера изображения в памяти. Хотя смотря о каком изображении идет речь. Если какой-нибудь 100000000000х100000000000, то возможно, но тут еще от кода зависит.

@T2skler · 12.10.2012, 14:45 **[ТС]**

Всё дело в том, что буфер используется для фона компонента и если постоянно изменять размер формы, то время изменения размера буфера с каждым разом увеличивается.
Routine Name UpdateBackgroundSize
Time 0,319427180124204
Time with Children 0,319427180124204
Shared Time 100
Hit Count 443
Максимальный размер битмапа примерно 500х500.

@DefineFalseTrue · 12.10.2012, 20:52

Я очень не рекомендую постоянно изменять размер изображения в этом плане. Поставьте какую-нибудь операцию (0,1-0,3 сек.) на событие при изменении размеров формы и поймете почему. В этом случае используйте контрольные точки и дополнительное резервирование размера. Допустим, у вас изначальный размер окна 640х480 - создавайте изображение 1280х960 и добавляйте 50% к его размеру, когда пользователь увеличит размер окна на 70-90%. В этом производительность возрастет в разы, т.к. основной упор будет идти на прорисовку. Допустим при изменении размера на 100 пикселей количетсво операций изменения размера будет равно 0. Особенно это будет заметно в ситуациях, когда пользователей подбирает размер окна и мышь двигается попеременно в разных направлениях.

Новые блоги и статьи Все статьи Все блоги /
Автозаполнение реквизита при выборе элемента справочника Maks 27.03.2026 Программный код из решения ниже на примере нетипового документа "ЗаявкаНаРемонтСпецтехники" разработанного в конфигурации КА2. При выборе "Спецтехники" (Тип Справочник. Спецтехника), заполняется. . .	Сумматор с применением элементов трёх состояний. Hrethgir 26.03.2026 Тут. https:/ / fips. ru/ EGD/ ab3c85c8-836d-4866-871b-c2f0c5d77fbc Первый документ красиво выглядит, но без схемы. Это конечно не даёт никаких плюсов автору, но тем не менее. . . всё может быть. . .	Автозаполнение реквизитов при создании документа Maks 26.03.2026 Программный код из решения ниже размещается в модуле объекта документа, в процедуре "ПриСозданииНаСервере". Алгоритм проверки заполнения реализован для исключения перезаписи значения реквизита,. . .	Команды формы и диалоговое окно Maks 26.03.2026 1. Команда формы "ЗаполнитьЗапчасти". Программный код из решения ниже на примере нетипового документа "ЗаявкаНаРемонтСпецтехники" разработанного в конфигурации КА2. В качестве источника данных. . .
Кому нужен AOT? DevAlt 26.03.2026 Решил сделать простой ланчер Написал заготовку: dotnet new console --aot -o UrlHandler var items = args. Split(":"); var tag = items; var id = items; var executable = args;. . .	Отправка уведомления на почту при изменении наименования справочника Maks 24.03.2026 Программная отправка письма электронной почты на примере изменения наименования типового справочника "Склады" в конфигурации БП3. Перед реализацией необходимо выполнить настройку системной учетной. . .	модель ЗдравоСохранения 5. Меньше увольнений- больше дохода! anaschu 24.03.2026 Теперь система здравосохранения уменьшает количество увольнений. 9TO2GP2bpX4 a42b81fb172ffc12ca589c7898261ccb/ https:/ / rutube. ru/ video/ a42b81fb172ffc12ca589c7898261ccb/ Слева синяя линия -. . .	Midnight Chicago Blues kumehtar 24.03.2026 Такой Midnight Chicago Blues, знаешь?. . Когда вечерние улицы становятся ночными, а ты не можешь уснуть. Ты идёшь в любимый старый бар, и бармен наливает тебе виски. Ты смотришь на пролетающие. . .

@T2skler 50 / 50 / 6 Регистрация: 16.05.2012 Сообщений: 232

	Изменение размера Bitmap 12.10.2012, 02:35. Показов 2689. Ответов 3 Метки нет (Все метки) В компоненте используется двойная буферизация. Пытался искать уязвимые по производительности функции и обнаружил, что больше всего времени требуется, чтобы изменить размер буферного битмапа. Подскажите, почему так происходит и почему заливка требует гораздо меньшего времени, чем изменение размера битмапа? 0

@DefineFalseTrue Заблокирован
	12.10.2012, 11:56
	Не замечал особых проблем с производительностью при изменении размера изображения в памяти. Хотя смотря о каком изображении идет речь. Если какой-нибудь 100000000000х100000000000, то возможно, но тут еще от кода зависит. 0

@T2skler 50 / 50 / 6 Регистрация: 16.05.2012 Сообщений: 232
	12.10.2012, 14:45 [ТС]
	Всё дело в том, что буфер используется для фона компонента и если постоянно изменять размер формы, то время изменения размера буфера с каждым разом увеличивается. Routine Name UpdateBackgroundSize Time 0,319427180124204 Time with Children 0,319427180124204 Shared Time 100 Hit Count 443 Максимальный размер битмапа примерно 500х500. 0

@DefineFalseTrue Заблокирован
	12.10.2012, 20:52
	Я очень не рекомендую постоянно изменять размер изображения в этом плане. Поставьте какую-нибудь операцию (0,1-0,3 сек.) на событие при изменении размеров формы и поймете почему. В этом случае используйте контрольные точки и дополнительное резервирование размера. Допустим, у вас изначальный размер окна 640х480 - создавайте изображение 1280х960 и добавляйте 50% к его размеру, когда пользователь увеличит размер окна на 70-90%. В этом производительность возрастет в разы, т.к. основной упор будет идти на прорисовку. Допустим при изменении размера на 100 пикселей количетсво операций изменения размера будет равно 0. Особенно это будет заметно в ситуациях, когда пользователей подбирает размер окна и мышь двигается попеременно в разных направлениях. 0