SASGIS - SAS.Планета
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0002710SAS.Планета[All Projects] Багpublic01-05-2015 22:1505-05-2015 11:22
Reportervasketsov 
Assigned Tovdemidov 
PrioritynormalSeveritytweakReproducibilityalways
StatusclosedResolutionno change required 
PlatformWindowsOS7OS VersionUltimate
Product Version 
Target VersionFixed in Version 
Summary0002710: Тормоза у счётчиков MatrixChangeRect
DescriptionЗакачек нет, включена только одна карта гугла, слои отключены, режим - только кэш. Ничего тяжёлого на компе не запущено.
На гугле меняю машстаб с z12 на z14.
Включен показ границ тайлов + метки (штук 20 на экране, из них три автомобильных трека, остальное границы изображений dg). В общем - сущая ерунда.

Так вот при подобном зуме отчётливо возникают непонятные тормоза.

Вот чего говорят счётчики производительности (из подозрительного):
/MapLayer/Composite/MatrixChangeRect 1 / 0.67538846 / 00:00.675
UI пусто
1.00402950 0.00000446

/MapLayer/Grids/MatrixChangeRect 1 / 0.57448734 / 0:00.574
UI пусто
0.57448734 0.00001297

/MapLayer/MainBitmapMaps/MatrixChangeRect / 1 / 0.31643584 / 0:00.316
UI пусто
0.32677460 0.00000365

/MapLayer/Marks/BitmapMatrix/MatrixChangeRect 1 / 0.42103580 / 00:00.421
UI пусто
0.42103580 0.00000365

/MapLayer/MiniMap/MatrixChangeRect 1 / 0.32023923 / 00:00.320
UI пусто
0.32023923 0.00000608

Отключил границы тайлов и миникарту, повторил эксперимент, результаты вот такие:

/MapLayer/Composite/MatrixChangeRect 1 / 0.6405287 / 00:00.641
UI пусто
1.00402950 0.00000446

/MapLayer/MainBitmapMaps/MatrixChangeRect 1 / 0.28553223 / 00:00.286
UI пусто
0.32677460 0.00000365

/MapLayer/Marks/BitmapMatrix/MatrixChangeRect 1 / 0.00000365 / 00:00.000
UI пусто
0.59408089 0.00000365

/MapLayer/Marks/VectorMatrix/MatrixChangeRect / 1 / 0.00001013 / 00:00.000
UI пусто
0.00394278 0.00000810

Это нормально?
Чем сас занимается порядка секунды и более при смене зума?

Что такого страшного делается внутри Grids/MatrixChangeRect, что оно занимает 0.6 секунды?
Что за сотворение мира происходит внутри Composite, что FPreparedBitmapMatrix.SetRect(VTileRect) занимает почти секунду (было даже больше секунды как то)?

Отключение MiniMap/MatrixChangeRect и Grids/MatrixChangeRect в сумме должно было дать порядка секунды - но визуально заметно, что принципиально продолжительность торможения при смене зума не изменилась, а если бы уменьшилась на секунду, это было бы заметно.

Или я неверно трактую показания счётчиков?
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
related to 0002714resolved vdemidov Добавить в TBitmapTileMatrixBuilder и TVectorTileMatrixBuilder признак необходимости перепроецирования тайлов 
Attached Files
Issue History
Date ModifiedUsernameFieldChange
01-05-2015 22:15vasketsovNew Issue
02-05-2015 13:18vdemidovNote Added: 0015806
02-05-2015 17:10vdemidovNote Added: 0015808
02-05-2015 19:12vasketsovNote Added: 0015809
02-05-2015 20:02vdemidovNote Added: 0015812
02-05-2015 21:11vasketsovNote Added: 0015814
02-05-2015 21:14vasketsovNote Edited: 0015814bug_revision_view_page.php?bugnote_id=15814#r6561
03-05-2015 06:18vdemidovNote Added: 0015817
03-05-2015 12:33vasketsovNote Added: 0015826
03-05-2015 12:58vasketsovNote Edited: 0015826bug_revision_view_page.php?bugnote_id=15826#r6563
03-05-2015 13:23vdemidovNote Added: 0015827
05-05-2015 07:06vdemidovNote Added: 0015839
05-05-2015 07:06vdemidovStatusnew => feedback
05-05-2015 08:53vasketsovNote Added: 0015843
05-05-2015 08:53vasketsovStatusfeedback => new
05-05-2015 09:00vdemidovNote Added: 0015844
05-05-2015 10:07vdemidovStatusnew => resolved
05-05-2015 10:07vdemidovResolutionopen => no change required
05-05-2015 10:07vdemidovAssigned To => vdemidov
05-05-2015 10:07vdemidovStatusresolved => closed
05-05-2015 10:14vdemidovRelationship addedrelated to 0002714
05-05-2015 11:02vasketsovNote Added: 0015848
05-05-2015 11:16vasketsovNote Edited: 0015848bug_revision_view_page.php?bugnote_id=15848#r6576
05-05-2015 11:22vdemidovNote Added: 0015850

Notes
(0015806)
vdemidov   
02-05-2015 13:18   
> Что такого страшного делается внутри Grids/MatrixChangeRect, что оно занимает 0.6 секунды?

Генерация тайлов 14-го зума из 12-го, хотя именно для сеток, скорее всего, можно отключить нафиг.
А вообще все эти операции выполняются на отдельных потоках и на ГУЙ должны влиять слабо.
(0015808)
vdemidov   
02-05-2015 17:10   
У меня, кстати, на очень хилом нетбуке /MapLayer/Composite/MatrixChangeRect занимает только 11 милисекунд
(0015809)
vasketsov   
02-05-2015 19:12   
>на очень хилом нетбуке
У меня Sony VAIO VGN-Z591U/B. ОС - Win7(x32).

Чтение меток занимает 0.3 секунды. Всё остальное - совершенно непонятные тормоза.
 
>11 милисекунд
Что там в принципе внутри Composite/MatrixChangeRect может так у меня тормозить?
Куда счётчик сунуть?

Могу ещё на x64 проверить. Но нужен волшебный пендаль, в каком направлении рыть.
(0015812)
vdemidov   
02-05-2015 20:02   
Может у тебя выбран ресамплер какой-то модный в настройках, а не Nearest?
(0015814)
vasketsov   
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   
03-05-2015 06:18   
> А возможно ли вообще отключить ресамплер при смене зума для всего левого (гридов, миникарты,...), и оставить только для основной карты, слоёв и меток?
Да, нужно будет так и сделать.

> Nearest самый быстрый?
Да. Есть еще Драфт, но он только для уменьшения, кажется.
Потом идет Линейный, потом все остальные.
(0015826)
vasketsov   
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   
03-05-2015 13:23   
Нужно переделывать статусбар. Кто ж спорит. Даже тикет такой давно есть. Отключи его и не будет лишних апдейтов экрана.
(0015839)
vdemidov   
05-05-2015 07:06   
Итого, что делаем с этим инцидентом? Просто закрываем как не требующий изменений или переделываем в "Убрать перепроецирование тайлов в FPreparedBitmapMatrix.SetRect(VTileRect) для некоторых слоев (сетки, карта заполнения, миникарта)"?
(0015843)
vasketsov   
05-05-2015 08:53   
Переделай, пожалуйста, с нужной формулировкой. Тебе виднее, где там можно убрать перепроецирование. Ну или может лучше закрой и новый роди.

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

Я ещё вчера посидел со счётчиками, но максимум что нашёл, это многократый паразитный вызов DoUpdateResultAndNotify внутри итератора while VTileIterator.Next(VTile) в u_BitmapTileMatrixChangeable*, предваряемый строкой типа FPreparedHashMatrix.Tiles[VTile] := VSourceHash, на которой, как мне кажется, уже можно понять, что элемент матрицы изменился, а не гонять MakeStatic.Hash. В общем, интуитивно чувствуется, что тут есть чего пооптимизировать, но мне пока что ума на это не хватило.
(0015844)
vdemidov   
05-05-2015 09:00   
>многократый паразитный вызов DoUpdateResultAndNotify внутри итератора while VTileIterator.Next(VTile)
Знаю. У меня еще есть сильное желание сделать этот вызов чуть отложенным (ну десяток миллисекунд) что бы он дергался только если с прошлого вызова прошло больше заданного времени или в конце цикла итератора while VTileIterator.Next(VTile), просто пока еще не придумал как это лучше сделать.
(0015848)
vasketsov   
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   
05-05-2015 11:22   
> обновление будет дважды через секунду. В общем, грустное зрелище.
Не, я имел в виду, что внутри цикла дергать только если прошлый раз дергали больше чем 10 мс назад, и в конце цикла дергать обязательно.
Но вообще нужно думать и пробовать.

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