У меня в Опере под виндовс открывается, но тормозит очень.
Можно написать, что “ваш браузер устарел, пользуйтесь современным браузером”.
Слева вверху есть выбор что раскрашивать градиентом и там есть список всех параметров, в том числе тех которых нет в треке. Ставишь раскрасить “спутники” и ничего не происходит, т.к. этой информации нет в треке. По моему их лучше или убрать или сделать не активными те варианты для которых нет информации.
Под картой таблица и в её заголовке 2 раза написана скорость (одна с большой буквы, другая с маленькой) - не понятно чем они отличаются. Нужно всплывающую подсказку сделать с описанием каждого параметра.
Тут вопрос в другом - считать ли его браузером? (*шутка) А по существу, как я писал выше, у меня нет винды, и я не могу проверить его работоспособность.
Там есть 3 скорости: реальная, вертикальная (скорость изменения высоты) и скорость с устройства. Вертикальная называется “↑ скорость”
Да, по всей видимости, так и придется делать. Сейчас попробую уменьшить выдаваемую информацию путем обрезки ненужных столбцов и включением сжатия.
Не запоминается - потому что пока не допилил. А лаги - это вот те самые тормоза отображения, про которые идет речь. Любое изменение отображения (изменение размера, скрытие, показ, форматирование) вызывает у браузера дикие тормоза.
Была такая мысль. Но, смотрите в чем особенность. Вот вы нажимаете кнопку “Показать трек”. Мне нужно отрисовать трек. Для этого мне нужны все точки трека. И где их хранить? Я пробовал заменить таблицу на блоки, но тут вырастает объем информации в 2-3 раза. Я пробовал использовать память JavaScript - крошится браузер. JSON вроде как использует какое-то хранилище, но он будет парсить еще долше, чем браузер сейчас таблицу отображает.
Грубо говоря, весь вопрос в том, где хранить распарсенные данные трека, чтобы браузер при этом не тормозил.
UPD: не совсем на тот вопрос ответил. По существу, браузеру пофиг, отображается таблица или нет - тормозит одинаково.
Это не так, сделать можно многое что. Скажем, генерализацию (оставив для отображения только нужное число точее). И многое другое.
Иные инструменты работы с треками тормозов не имеют.
На текущий момент, по моему мнению, нужно заниматься, в первую очередь, оптимизацией, а не внедрением новых возможностей.
Тормозов быть не должно.
Пока анализатор (с учетом наличия нетормозящих альтернатив) для практического использования малопригоден. Однако, веб-сервис с упомянутыми выше возможностями весьма полезен и я надеюсь, что автор приведет его к пригодному для практических целей виду.
Действительно, некоторые инструменты упрощают трек на мелких масштабах, и показывают больше деталей при увеличении, таким образом, отображая на экране всегда ограниченное число точек.
Что имелось ввиду под “память JavaScript”? Массив?
Использовать хтмл таблицу для хранения данных - это самое неожиданное, что я мог услышать Я думал, она только для отображения…
Объясни это браузеру, который отводит для таблицы отдельную область памяти.
UPD: но от этого я уже ушел, теперь вот вопрос, как выводить список точек.
Вы наверное не поняли, но на данный момент основная задача сделать так, чтобы трек не ХРАНИЛСЯ где-то, подгружаясь оттуда частями, а загружался в браузер пользователя и там обрабатывался. Никакого нового хранилища треков я делать не собираюсь. Поэтому очень бы хотелось посмотреть на альтернативные инструменты.
Пока я делал для себя, я имел дело максимум с 30000 точек с трека за 12 дней. Оказалось, что есть треки и на 500000 точек. Так же оказалось, что треки бывают заархивированы, и что бывают заархивированы целые папки. А это уже до 3 миллионов точек. Также оказалось, что браузеры замножают используемую память под любые массивы до 5 раз. Просто попробуйте сохранить в памяти 10000 строчек по 5 значений в любом виде - уже заметно скажется на производительности. Также у разных браузеров оказались разные узкие места: огнелис ворочает таблицами шустрее, хром с памятью бережнее обращается, опера… не будем о грустном…
В общем, вы вникните в суть проблемы для начала, я несколько дней назад даже представить не мог тех проблем, над которыми бьюсь в последнее время.
Трек сейчас с вашего сервера загружается. Можно сделать что бы он сразу на страничку загружался, без использования вашего сервера? Или вы трек все же как-то обрабатываете на сервере? В результате можно будет оффлайн использовать анализатор и трек не будет никуда загружаться и не будет доступен всему интернету.
localStorage и webSQL это скорее для оффлайнового хранения, туда помещаются данные, которые нужно хранить между посещениями страницы. Для хранения текущих данных они не подходят.
Да, это я уже тоже выяснил. Тем более, что опера вобще только с 5Мб может работать. Сейчас кручу XML в собственном формате со сжатием. Жаль только , тестеров нет. Уж больно дома компы все мощные. Я не мог понять, чего люди недовольны текущей версией, пока у клиента на обычном компе не запустил. А на моих двух ноутах даже текущая версия работает нормально, тормоза только при скрытии/показе колонок.
Ну так… Те же яйца, только в профиль. Но я именно JSON и имел ввиду.
В планах прикрутить фильтр, но для начала будет сделан выбор части трека для анализа. Вот только с тормозами разберусь.
По адресу http://gpx2.lisss.ru доступна разрабатываемая версия. Там есть техническая информация по треку.
Посмотреть результаты работы на большихи маленьких треках, оценить личные ощущения браузеров от работы.
Большие треки я тестирую на пользователе AHTOH. Не рекомендую пытаться загрузить треки по 500000 точек - валиться браузер. Работает в Firefox и Chrome.
Таблица точек пока отсутствует, как основная причина тормозов. Думаю пока, чем заменить.