0002710: Тормоза у счётчиков MatrixChangeRect

Notes
(0015806) vdemidov (manager) 02-05-2015 13:18	> Что такого страшного делается внутри Grids/MatrixChangeRect, что оно занимает 0.6 секунды? Генерация тайлов 14-го зума из 12-го, хотя именно для сеток, скорее всего, можно отключить нафиг. А вообще все эти операции выполняются на отдельных потоках и на ГУЙ должны влиять слабо.

(0015808) vdemidov (manager) 02-05-2015 17:10	У меня, кстати, на очень хилом нетбуке /MapLayer/Composite/MatrixChangeRect занимает только 11 милисекунд

(0015809) vasketsov (manager) 02-05-2015 19:12	>на очень хилом нетбуке У меня Sony VAIO VGN-Z591U/B. ОС - Win7(x32). Чтение меток занимает 0.3 секунды. Всё остальное - совершенно непонятные тормоза. >11 милисекунд Что там в принципе внутри Composite/MatrixChangeRect может так у меня тормозить? Куда счётчик сунуть? Могу ещё на x64 проверить. Но нужен волшебный пендаль, в каком направлении рыть.

(0015812) vdemidov (manager) 02-05-2015 20:02	Может у тебя выбран ресамплер какой-то модный в настройках, а не Nearest?

(0015814) vasketsov (manager) 02-05-2015 21:11 edited on: 02-05-2015 21:14	Ну, если выбрать Nearest для смены зума (был Lanczos), то этот переход работает заметно быстрее. С Nearest и с метками: /MapLayer/Composite/MatrixChangeRect 1 / 0.07345505/ 00:00.073 /MapLayer/Marks/BitmapMatrix/MatrixChangeRect 1 / 0.02865563 / 00:00.029 Будем считать, что дело было в этом. Спасибо. А возможно ли вообще отключить ресамплер при смене зума для всего левого (гридов, миникарты,...), и оставить только для основной карты, слоёв и меток? Nearest самый быстрый?

(0015817) vdemidov (manager) 03-05-2015 06:18	> А возможно ли вообще отключить ресамплер при смене зума для всего левого (гридов, миникарты,...), и оставить только для основной карты, слоёв и меток? Да, нужно будет так и сделать. > Nearest самый быстрый? Да. Есть еще Драфт, но он только для уменьшения, кажется. Потом идет Линейный, потом все остальные.

(0015826) vasketsov (manager) 03-05-2015 12:33 edited on: 03-05-2015 12:58	А вообще конечно странностей ещё полно. Например, загружена карта без слоёв и метки. Мышка в окне debug и не двигается. А между тем /MapLayer/Composite/OneTilePaintSimple отстреливает ежесекундно примерно 70-90 раз. Зачем и что там рисуется, если ничего не меняется? /MapLayer/StatusBar/Redraw тоже с десяток раз в секунду стреляет, хотя ничего не меняется, зачем? procedure TWindowLayerStatusBar.OnTimerEvent; begin ViewUpdateLock; try SetNeedUpdateBitmapDraw; finally ViewUpdateUnlock; end; end; То есть, по таймеру постоянно перерисовываемся (зовём DoUpdateBitmapDraw) неизвестно зачем?

(0015827) vdemidov (manager) 03-05-2015 13:23	Нужно переделывать статусбар. Кто ж спорит. Даже тикет такой давно есть. Отключи его и не будет лишних апдейтов экрана.

(0015839) vdemidov (manager) 05-05-2015 07:06	Итого, что делаем с этим инцидентом? Просто закрываем как не требующий изменений или переделываем в "Убрать перепроецирование тайлов в FPreparedBitmapMatrix.SetRect(VTileRect) для некоторых слоев (сетки, карта заполнения, миникарта)"?

(0015843) vasketsov (manager) 05-05-2015 08:53	Переделай, пожалуйста, с нужной формулировкой. Тебе виднее, где там можно убрать перепроецирование. Ну или может лучше закрой и новый роди. В принципе, изначальная проблема решена, так как перепроецирование оставшихся слоёв матриц сейчас не вносит серьёзных тормозов, хотя конечно тоже никому не нужно. Я ещё вчера посидел со счётчиками, но максимум что нашёл, это многократый паразитный вызов DoUpdateResultAndNotify внутри итератора while VTileIterator.Next(VTile) в u_BitmapTileMatrixChangeable*, предваряемый строкой типа FPreparedHashMatrix.Tiles[VTile] := VSourceHash, на которой, как мне кажется, уже можно понять, что элемент матрицы изменился, а не гонять MakeStatic.Hash. В общем, интуитивно чувствуется, что тут есть чего пооптимизировать, но мне пока что ума на это не хватило.

(0015844) vdemidov (manager) 05-05-2015 09:00	>многократый паразитный вызов DoUpdateResultAndNotify внутри итератора while VTileIterator.Next(VTile) Знаю. У меня еще есть сильное желание сделать этот вызов чуть отложенным (ну десяток миллисекунд) что бы он дергался только если с прошлого вызова прошло больше заданного времени или в конце цикла итератора while VTileIterator.Next(VTile), просто пока еще не придумал как это лучше сделать.

(0015848) vasketsov (manager) 05-05-2015 11:02 edited on: 05-05-2015 11:16	>или в конце цикла итератора while VTileIterator.Next(VTile) Так нельзя делать. Я пробовал ))) Обновление картинки будет происходить при изменении зума раз в секунду. Даже когда все тайлы уже в наличии, но не успели загрузиться за секунду (например, по сетке), обновление будет дважды через секунду. В общем, грустное зрелище. Сейчас признак VChanged поднимается внутри DoUpdateResultAndNotify и синхронно с ним меняется FResult под блокировкой. Я бы, как руки у тебя дойдут, предложил попробовал простой вариант без таймаутов. Снаружи в местах типа FPreparedHashMatrix.Tiles[VTile] := VSourceHash поднимать признак типа VChanged, например, FHashChanged ). Это можно делать вообще без синхронизации, чтение и запись байта всегда атомарны (а можно красивее через Interlocked). А вот уже при попытке доступа к FResult смотреть FHashChanged и при наобходимости генерить адекватный FResult, сбрасывая FHashChanged. Потому что сейчас перечень операций: FPreparedBitmapMatrix.MakeStatic; CS.BeginWrite; Result.Hash; выполняются только лишь для того, чтобы сделать FResult := VResult; при этом мы уже точно на входе в DoUpdateResultAndNotify знаем, что в конце итератора с вероятностью 99% что-нибудь, да изменится, возможно не при текущем исполнении DoUpdateResultAndNotify, а в следующий раз. Я сам бы поигрался, да вот пока ещё не совсем разобрался с матрицами, некогда всё, боюсь 99% накосячу и откачу изменения возможно из-за мелочи, которую просто не заметил. ------- *) возможно, прокатит просто сразу позвать DoChangeNotify.

(0015850) vdemidov (manager) 05-05-2015 11:22	> обновление будет дважды через секунду. В общем, грустное зрелище. Не, я имел в виду, что внутри цикла дергать только если прошлый раз дергали больше чем 10 мс назад, и в конце цикла дергать обязательно. Но вообще нужно думать и пробовать. А насчет всего остального тоже нужно думать. Я делал максимально простой вариант, что бы убедится в общей работоспособности. Оптимизировать там много чего можно.

Users who viewed this issue
User List	Anonymous (2013x)
Total Views	2013
Last View	20-04-2024 08:46

Issue History
Date Modified	Username	Field	Change
01-05-2015 22:15	vasketsov	New Issue
02-05-2015 13:18	vdemidov	Note Added: 0015806
02-05-2015 17:10	vdemidov	Note Added: 0015808
02-05-2015 19:12	vasketsov	Note Added: 0015809
02-05-2015 20:02	vdemidov	Note Added: 0015812
02-05-2015 21:11	vasketsov	Note Added: 0015814
02-05-2015 21:14	vasketsov	Note Edited: 0015814	View Revisions
03-05-2015 06:18	vdemidov	Note Added: 0015817
03-05-2015 12:33	vasketsov	Note Added: 0015826
03-05-2015 12:58	vasketsov	Note Edited: 0015826	View Revisions
03-05-2015 13:23	vdemidov	Note Added: 0015827
05-05-2015 07:06	vdemidov	Note Added: 0015839
05-05-2015 07:06	vdemidov	Status	new => feedback
05-05-2015 08:53	vasketsov	Note Added: 0015843
05-05-2015 08:53	vasketsov	Status	feedback => new
05-05-2015 09:00	vdemidov	Note Added: 0015844
05-05-2015 10:07	vdemidov	Status	new => resolved
05-05-2015 10:07	vdemidov	Resolution	open => no change required
05-05-2015 10:07	vdemidov	Assigned To	=> vdemidov
05-05-2015 10:07	vdemidov	Status	resolved => closed
05-05-2015 10:14	vdemidov	Relationship added	related to 0002714
05-05-2015 11:02	vasketsov	Note Added: 0015848
05-05-2015 11:16	vasketsov	Note Edited: 0015848	View Revisions
05-05-2015 11:22	vdemidov	Note Added: 0015850

SASGIS