Недавно заметил торможение ОЗИ на длинных треках. При накоплении трека длиной более 400 КМ ОЗИ начинает все больше и болше подтормаживать , причем хитро так: На стоянке не тормозит, но стоИт поехать и набрать скорость более 70 КМ/Ч начинаются тормоза. (визуально наблюдается замедление отображения приема данных с GPS в соотв. строке, при попытке выбрать чего- нить из меню жуткие тормоза) С 600-КМ треком ОЗИ уже еле ворочается.
Как и советовали, обновился - ноль эмоций.
Так что проблема остается нерешенной.
Стас.
Возвращаясь к длинным трекам в ОЗИ
Правила форума
Для предотврашения спама первые сообщения вновь зарегистрированных пользователей проходят ручную премодерацию.
Для предотврашения спама первые сообщения вновь зарегистрированных пользователей проходят ручную премодерацию.
|
||
 |
||
Re: Возвращаясь к длинным трекам в ОЗИ
7800-км трек - проблем замечено не было. Версия 3.95.4h.
Re: Возвращаясь к длинным трекам в ОЗИ
В такой ситуации помогает включение ограничения на отображение последних точек трека, которое задается параметром Track Tail Lenght в настройках.
Проблема есть
Действительно, с увеличением длинн отображаемых треков ози начинает тормозиться. Однако это очень сильно зависит от производительности процессора.
Так, к примру, у меня карта Московской области с наложенным на неё треком из 50000 точек (надо мерить не в дистанции, а в числе отображаемых точек) на лептопе с Пентиум М на 1.7 GHz и 512 MB рисуется в лёт и без проблем, хотя незначительное замедление все же на глаз заметно. В то же время на той же математике, но на другом лептопе с CoreTMDuo 1.06GHz и такой же памятью отрисовка вызывает уже некоторые затруднения, а установка на Либретту (не поню что там, но что-то первое из пентиумов) показала полную невозможность работы с такой картой.
При этом у первых двух лептопов видео процессор приблизительно одинаков, а кеш у второго даже лучше. Из чего был сделан вывод о неэффективнсти алгоритма отображения треков в Ози.
Выходов как всегда несколько:
- рисовать меньше треков. Часто помогает, но не всегда интересно
- наносить треки в виде рисунка на исходную карту.
Второй подход был изобретен с появлением OziCE - на очень маломошных тогда покетах у него отрисовка трека и в 500 точек вызывала трудности. Поступали просто - в большом ози наносили трек на карту, экспериментально подбирали его толщину для лучшей читаемости на наиболее часто используемых масштабах, выводили карту вместе с треками в граф файл и полученный граф файл преобразовывали в OZF и использовали со старым файлом привязки.
Подход оказался весьма плодотворен - на вновь создаваемую карту можно нанести не только треки, но и любую другую информацию, и использовать затем её на маломощных компах.
У такого подхода есть два заметных минуса:
- при появлении новых данных карту приходится перегенерировать. Одновременно возникает необходимость для процесса перегенерации держать и исходную карту.
- при масштабировании такой карты линии треков также масштабируются и могут стать либо слишком толстыми, либо тонкими для восприятия. Однако с этим приходится мириться.
Михаил.
Так, к примру, у меня карта Московской области с наложенным на неё треком из 50000 точек (надо мерить не в дистанции, а в числе отображаемых точек) на лептопе с Пентиум М на 1.7 GHz и 512 MB рисуется в лёт и без проблем, хотя незначительное замедление все же на глаз заметно. В то же время на той же математике, но на другом лептопе с CoreTMDuo 1.06GHz и такой же памятью отрисовка вызывает уже некоторые затруднения, а установка на Либретту (не поню что там, но что-то первое из пентиумов) показала полную невозможность работы с такой картой.
При этом у первых двух лептопов видео процессор приблизительно одинаков, а кеш у второго даже лучше. Из чего был сделан вывод о неэффективнсти алгоритма отображения треков в Ози.
Выходов как всегда несколько:
- рисовать меньше треков. Часто помогает, но не всегда интересно
- наносить треки в виде рисунка на исходную карту.
Второй подход был изобретен с появлением OziCE - на очень маломошных тогда покетах у него отрисовка трека и в 500 точек вызывала трудности. Поступали просто - в большом ози наносили трек на карту, экспериментально подбирали его толщину для лучшей читаемости на наиболее часто используемых масштабах, выводили карту вместе с треками в граф файл и полученный граф файл преобразовывали в OZF и использовали со старым файлом привязки.
Подход оказался весьма плодотворен - на вновь создаваемую карту можно нанести не только треки, но и любую другую информацию, и использовать затем её на маломощных компах.
У такого подхода есть два заметных минуса:
- при появлении новых данных карту приходится перегенерировать. Одновременно возникает необходимость для процесса перегенерации держать и исходную карту.
- при масштабировании такой карты линии треков также масштабируются и могут стать либо слишком толстыми, либо тонкими для восприятия. Однако с этим приходится мириться.
Михаил.
Проблема есть
Действительно, с увеличением длинн отображаемых треков ози начинает тормозиться. Однако это очень сильно зависит от производительности процессора.
Так, к примру, у меня карта Московской области с наложенным на неё треком из 50000 точек (надо мерить не в дистанции, а в числе отображаемых точек) на лептопе с Пентиум М на 1.7 GHz и 512 MB рисуется в лёт и без проблем, хотя незначительное замедление все же на глаз заметно. В то же время на той же математике, но на другом лептопе с CoreTMDuo 1.06GHz и такой же памятью отрисовка вызывает уже некоторые затруднения, а установка на Либретту (не поню что там, но что-то первое из пентиумов) показала полную невозможность работы с такой картой.
При этом у первых двух лептопов видео процессор приблизительно одинаков, а кеш у второго даже лучше. Из чего был сделан вывод о неэффективнсти алгоритма отображения треков в Ози.
Выходов как всегда несколько:
- рисовать меньше треков. Часто помогает, но не всегда интересно
- наносить треки в виде рисунка на исходную карту.
Второй подход был изобретен с появлением OziCE - на очень маломошных тогда покетах у него отрисовка трека и в 500 точек вызывала трудности. Поступали просто - в большом ози наносили трек на карту, экспериментально подбирали его толщину для лучшей читаемости на наиболее часто используемых масштабах, выводили карту вместе с треками в граф файл и полученный граф файл преобразовывали в OZF и использовали со старым файлом привязки.
Подход оказался весьма плодотворен - на вновь создаваемую карту можно нанести не только треки, но и любую другую информацию, и использовать затем её на маломощных компах.
У такого подхода есть два заметных минуса:
- при появлении новых данных карту приходится перегенерировать. Одновременно возникает необходимость для процесса перегенерации держать и исходную карту.
- при масштабировании такой карты линии треков также масштабируются и могут стать либо слишком толстыми, либо тонкими для восприятия. Однако с этим приходится мириться.
Михаил.
Так, к примру, у меня карта Московской области с наложенным на неё треком из 50000 точек (надо мерить не в дистанции, а в числе отображаемых точек) на лептопе с Пентиум М на 1.7 GHz и 512 MB рисуется в лёт и без проблем, хотя незначительное замедление все же на глаз заметно. В то же время на той же математике, но на другом лептопе с CoreTMDuo 1.06GHz и такой же памятью отрисовка вызывает уже некоторые затруднения, а установка на Либретту (не поню что там, но что-то первое из пентиумов) показала полную невозможность работы с такой картой.
При этом у первых двух лептопов видео процессор приблизительно одинаков, а кеш у второго даже лучше. Из чего был сделан вывод о неэффективнсти алгоритма отображения треков в Ози.
Выходов как всегда несколько:
- рисовать меньше треков. Часто помогает, но не всегда интересно
- наносить треки в виде рисунка на исходную карту.
Второй подход был изобретен с появлением OziCE - на очень маломошных тогда покетах у него отрисовка трека и в 500 точек вызывала трудности. Поступали просто - в большом ози наносили трек на карту, экспериментально подбирали его толщину для лучшей читаемости на наиболее часто используемых масштабах, выводили карту вместе с треками в граф файл и полученный граф файл преобразовывали в OZF и использовали со старым файлом привязки.
Подход оказался весьма плодотворен - на вновь создаваемую карту можно нанести не только треки, но и любую другую информацию, и использовать затем её на маломощных компах.
У такого подхода есть два заметных минуса:
- при появлении новых данных карту приходится перегенерировать. Одновременно возникает необходимость для процесса перегенерации держать и исходную карту.
- при масштабировании такой карты линии треков также масштабируются и могут стать либо слишком толстыми, либо тонкими для восприятия. Однако с этим приходится мириться.
Михаил.
|
||
|
||
Re: Возвращаясь к длинным трекам в ОЗИ
Track Tail действует на трек который сейчас пишется, а речь идет о загруженных треках.
С уважением, Евгений
С уважением, Евгений
Re: Возвращаясь к длинным трекам в ОЗИ
В связи со взрывом компа долго был в офф-лайне.
Valentin спасибо, попробую.
2all: речь идет в основном про отображение текущего трека. Вчера в техподдержку на офсайт написАл (ОЗИ лицензионный), ответа пока нет. Наверное не будет, т.к. автор ИМХО прекратил оптимизировать прогу для старых компов: в 3.70 озф-карты на 4х86-133 летают, но если поставить 3.95 - начинаются жуткие тормоза. У меня ноут НН3, Пень-3 400Мгц, пришлось откатываться на 3.95.2, иначе жутко долго грузится поиск по имени.
Стас.
Valentin спасибо, попробую.
2all: речь идет в основном про отображение текущего трека. Вчера в техподдержку на офсайт написАл (ОЗИ лицензионный), ответа пока нет. Наверное не будет, т.к. автор ИМХО прекратил оптимизировать прогу для старых компов: в 3.70 озф-карты на 4х86-133 летают, но если поставить 3.95 - начинаются жуткие тормоза. У меня ноут НН3, Пень-3 400Мгц, пришлось откатываться на 3.95.2, иначе жутко долго грузится поиск по имени.
Стас.
Кто сейчас на конференции
Сейчас этот форум просматривают: Bing [Bot] и 85 гостей