Много динамических компонентов - это медленно
void CreateNextComponents(TPanel * pContainer, TPoint &Position)
{
TImage * pImage = new TImage(pContainer);
pImage->Parent = pContainer;
pImage->Left = Position.x;
pImage->Top = Position.y;
}
при этом если убрать "pImage->Parent = pContainer;" то все нормально.
Незначительно ускоряет процесс невибимость pContainer.
Я предпологаю, что каждый компонент при создании заносится в какой-то сверхьь-неоптимизированный динамический список данной панели. Может кто знает как ускорить этот процесс.
Да и еще. Code insit у меня так тормозит, что если нажать случайно Ctrl+Space то обождать прийдется несколько минут. В начале я думал, что это из-за большого проекта (более 200 *.cpp файлов ), но когда открыть его в Visual studio все работает мгновенно (правда использую Visual Assist - супер штуковина). Кто может сталкивался с подобным?
при этом если убрать "pImage->Parent = pContainer;" то все нормально.
Незначительно ускоряет процесс невибимость pContainer.
Я предпологаю, что каждый компонент при создании заносится в какой-то сверхьь-неоптимизированный динамический список данной панели. Может кто знает как ускорить этот процесс.
Указывая адрес объекта X для значения свойства parent (родитель) объекта Y, вы добавляете адрес объекта Y в список Controls объекта X.
Конечно же, хранение 2500*4 = 10КБ информации - это пустяк для любого нормального списка. Но вот только индексируемое свойство Controls используется для прорисовки всех указанных объектов. А Выполнять перерисовку такого количества визуальных компонентов внутри одного окна - весьма накладно :(.
Может в консерватории (условии задания) править надо???
Конечно же, хранение 2500*4 = 10КБ информации - это пустяк для любого нормального списка. Но вот только индексируемое свойство Controls используется для прорисовки всех указанных объектов. А Выполнять перерисовку такого количества визуальных компонентов внутри одного окна - весьма накладно :(.
Может в консерватории (условии задания) править надо???
Хорошо допустим, что дело в прорисовке, однако после того как все объекты были созданы тормозов не наблюдалось, даже с интенисивными "m_pImage->Picture->Assign(...)" и "m_pImage->Picture->Repaint()", и даже при обновлении по таймеру в 200 мс самой панели с объектами все летало. Если бы дело бало-бы только в прорисовке, то после 2-х минутной процедуры создания объектов на панели, прорисовка этой панели должна была бы длиться приблизительно столько-же. К тому же операция прорисовки невидимого окно в Windows дело шустрое.
А задание то еще похуже: создовать поле 1500X1500 с разнообразными картинками и по одельности их сменять, да и выбирать не приходится.
Угу. Похоже, дело табак. При таком количестве объектов задержка происходит, по всей видимости, из-за неэффективного перераспределения памяти в списках типа TList FControls и FComponents.
Хреновей всего, что проблема, на первый взгляд, нерешаема без переписывания TComponent и TWinControl, что, сам понимаешь, кхем... Достаточно ведь в нужном месте добавить FComponents.Capacity := <нужное число>. Но оно внутри Classes. Нда.
Похоже, дело действительно в "консерватории", точнее, способе решения. Придётся создавать собственный компонент, позволяющий хранить и рисовать набор из большого числа мелких кусочков без подобных накладных расходов. Ну, или тупо хранить в TList с предварительно установленным Capacity, а рисовать вручную, через Image1.Picture.Bitmap.Canvas.Draw(336, 10, Piece122);
А если и понадобились то проще воспользоватся регионами и уже в них врисовывать нужную картинку...
ТАк же в дальнейшем можно отследить над каким регионом наведена мышь или на какой регион нажали мышью!
Работать будет мгновенно и ресурсов сьест меньше!
А если и понадобились то проще воспользоватся регионами и уже в них врисовывать нужную картинку...
ТАк же в дальнейшем можно отследить над каким регионом наведена мышь или на какой регион нажали мышью!
Работать будет мгновенно и ресурсов сьест меньше!
Совет замечательный. Все летало, но заказчик гифки навязывает, и на уступки неидет, может еще есть варианты
Вариант есть!
Если найдешь копанент который будет проигрывать GIF формат и сможешь расплодить его до 2500 копий без всяких ошибок то:
Во время создавания нового объекта и присваения ему родителя самого родителя сделай невидемым. (это сократит время создавания)
А как все создашь покажи родителя с готовыми картинками.
А еще один вариант, если заказчик такой требовательный мол чтобы быстро все и сразу и ждать не могу 2 минуты, то скажи есть такая весЧ как системные требования ПО! :)
Вариант есть!
Если найдешь копанент который будет проигрывать GIF формат и сможешь расплодить его до 2500 копий без всяких ошибок то:
Во время создавания нового объекта и присваения ему родителя самого родителя сделай невидемым. (это сократит время создавания)
А как все создашь покажи родителя с готовыми картинками.
Я понимаю нащет гиф, TImage был к примеру. Идея сделать компонент невидимым хорошая, но не слишком увеличивает скорость создания, зато насчет требования ПО я стобой согласен на все 100%