Notes |
|
(0006321)
|
Tolik
|
29-03-2012 06:45
|
|
> б) построение карты заполнения для нового участка экрана после небольшого сдвига;
Привычно (и правильно), что карта заполнения после сдвига обновляется полностью.
Если при сдвиге обновлять не всю, а только ту область, которая появилась на экране, может оказаться, что центральная часть карты зап. устарела (если смотреть её одновременно с закачкой). |
|
|
(0006322)
|
vasketsov
|
29-03-2012 06:51
(edited on: 29-03-2012 06:53) |
|
>центральная часть карты зап. устарела (если смотреть её одновременно с закачкой).
Эту проблему надо решать немного по-другому, а именно - сбросом признака валидности с карты заполнения и перестроением её при произвольном минимальном сдвиге (а не как сейчас надо сильно сдвинуть). Коли уж тайлы на лету обновляются после закачки, то "известить" слой карты заполнения об изменениях также не проблема.
В любом случае конкретно эта доработка не ставит целью изменение исходных параметров карты заполнения, как она строилась по всему экрану, так и будет строиться. Как не показывала карта через 180 градусов - так и не будет показывать после этой доработки. Это просто указание на то, что диапазон не обязательно совпадает с экраном.
|
|
|
(0006361)
|
vasketsov
|
02-04-2012 11:42
(edited on: 02-04-2012 11:49) |
|
Задуманное сделал, ускорение отрисовки карты заполнения для GE заметно (но правда не в разы, потому что до последнего необработанного тайла надо идти до конца индекса, индекс маленький, а больше +4 я не запускал).
Но могу "обрадовать". Налетел на совершенно непонятную багу. Крэшится в SysUtils внутри совершенно безобидного IntToStr. Крэшится ТОЛЬКО если включить карту заполнения, и не дав ей дорисоваться, сдвинуть карту (чтобы рисовалась по-новой). Судя по стеку - гадит обработка исключений (вызывается рекурсивно). Замена MemoryManager в DLL на FastMM или сасовский ничего принципиально не меняет. Даже обернул получение битовой карты тайлов в BeginWrite..EndWrite - пофигу.
На самом деле крайне редко при установленной версии аналогично валится и "старая" DLL, где нет функции получения битовой карты для тайлов.
|
|
|
|
А ты в dll прописал IsMultiThread := true |
|
|
(0006363)
|
vasketsov
|
02-04-2012 12:14
(edited on: 02-04-2012 12:16) |
|
О, заметно полегчало, ведь чувствовал что что-то забыл. Но всё равно (пусть и сильно реже) где-то крэшится. Походу надо ещё попробовать MainInstance передать в DLL.
Врубил "еврику" на EXE и DLL и словил приаттаченное.
|
|
|
|
Ну это похоже та же проблема, что и у Паразита в соседней хотелке. Скоро вылечиться. Глобальных локов просто не будет. Можешь посмотреть на новый основной слой. Правда он еще не до конца доделан. |
|
|
|
Пока что сделал только для GE. Приаттачил DLL в доработку 0001195. Работает и потайлово, и по битовой карте.
Общая логика:
0. Карта заполнения по битовой карте тайлов строится ТОЛЬКО если исходный зум строго больше текущего.
1. Хранилище (а кроме него собственно некому) определяет формат (и размер) буфера для битовой карты тайлов в заданном диапазоне (*).
2. Создаётся пустой чистый буфер.
3. Зовётся хранилище, далее вызов улетает в DLL (если хранилище в DLL). Соответственно в сасе не кэшируется.
4. По возвращению из DLL буфер заполнен в соответствии с заказанным форматом. Если DLL не поддерживает заказанный хранилищем формат - ломаем руки автору хранилища и по совместительству DLL.
5. Покуда может кинуться EOutOfMemory - хранилище не должно требовать именно заказанного формата буфера, может быть и попроще (например, только флаги).
6. Разбор буфера и вызов раскраски тайлов.
(*) Если есть даты - один формат, если нет - другой. Цель - по возможности минимизировать требуемый размер буфера. А то для 60 тайлов текущего зума для +8 в случае построения карты заполнения до диапазону дат для 12 байт на "микротайл" может быть совсем грустно, при сильной фрагментации ждать выделения будем долго.
Сейчас предусмотрены форматы 1, 4 и 8 байт на "макротайл" (1 - только флаги, 4 - дата и время с точностью до 30 секунд + флаги, 8 - полный диапазон TDateTime + флаги). |
|