Скайп превратился в уродливого ненастраиваемого монстра, для которого, по сути, нет альтернативных клиентов. Ваши запросы не совпадают с тем, как видят развитие этого сервиса product manager-ы из Microsoft? Считайте, вам не повезло.
Bridge показывает вам отдельно сгенерированное preview (thumbnail).
Решение - использовать действительно предназначенный для этого софт - https://www.fastrawviewer.com
Ingernirated: Про это не читать, а смотреть нужно. Идите на Youtube и смотрите видео по ключевым словам "VLog L", "video grading" "DaVinci resolve". Из этого можно получить представление.
Встречный вопрос: а вы видели картинку непосредственно из цифровой кинокамеры, без обязательного grading-а (потому что камера снимает в сыром формате с логарифмической кривой яркостей), без пост-обработки, тонировки, эффектов?
И почему столько людей пытаются слепо верить тому, что выдает им PageSpeed? Он же абсолютно ничего не знает о том, на что ориентируется владелец контента - он просто предупреждает о том, что изображения, вероятно, стоит еще сжать. Если это не входит в ваши планы, то зачем пыжиться, чтобы угодить PageSpeed?
В действительности, для JPEG можно, например, усилить сжатие, но отключить chroma subsampling, или наоборот, использовать более грубые настройки chroma subsampling, но уменьшить сжатие. Это зависит от содержимого изображения и требует понимания того, что делаешь. А подгонка под формальный тест ни к чему хорошему не приводит.
То, на что вы жалуетесь, это tooltip-ы, показывающие содержимое атрибута title у ссылок.
Самый надёжный способ, вероятно, вооружиться каким-нибудь greasemonkey-скриптом и просто удалять их в коде.
Programep: всё, что я предлагаю - это объяснение ситуации.
Говоря о "тех же уловиях", вы имеете в виду, что у вас есть, как минимум, два устройства, которые лежат рядом и на одном положение скачет, а на другом - нет? Если это не параллельное тестирование, а ваш прошлый опыт, то разница может объясняться простой случайностью.
Если все же сравнение объективно, то я могу предположить, что в приложении на google api либо добавлена проверка на то, что чтобы точность не срывалась ниже какой-то определенной, либо происходит банальное сравнение координат с прошлыми и значения, которые отличаются на какую-то большую величину, просто выбрасываются.
И перестаньте, наконец, упоминать OpenStreetMap. OSM вообще не имеет Location API, не определяет никакие координаты и так далее. Уж говорите тогда про Leaflet.js (который также не является частью OSM).
Вообще, если вчитаться, то в примере расстояние вычисляется в обоих случаях в двумерном пространстве, т.к. в случае, когда p1 и p2 - массивы из шести элементов, расстояние вычисляется только из первых двух элементов.
А что содержат остальные - может быть совершенно неважно, так как это может быть не запись координат точки, а строка из типичной для ГИС таблицы, где в первых столбцах - координаты, а в остальных - что угодно, включая температуру или направление ветра.
Меня в таком "задании" смутило бы отсутствие описания переменных и я бы его отказался делать без этого.
Programep: вот именно что "подобные" - то, какая используется картинка с картой, абсолютно никак на определение координат не влияет. Я же вам сказал, что не имеет OSM к вашей проблеме никакого отношения.
А ваша проблема связана, вероятнее всего, с условиями приема спутников в данном конкретном случае. GPS - штука не с гарантированной надёжностью. И ни используемая карта, ни используемый картографический фреймворк, к этой ситуации никакого отношения также не имеют.
