Комментарии 49
Если бага была в отрисовке слоев, то почему она не проявлялась в отрисовке других полупрозрачных компонентов?
Это уже вопрос к msvc2013, как я понял.
Не совсем понятно про какие компоненты идет речь.
Но если предположить, что про что-то простое типа css свойства opacity, то тут надо немного рассказать как хром рисует веб-странички.
Предположим, что у вас есть страничка с двумя статичными полупрозрачными изображениями.
Хром ( а реально WebKit ) заранее просчитает финальную картинку, которая получается при смешивании этих двух статичных картинок и браузер уже нарисует финальную картинку.
Однако, если что-то поменяется, надо будет перерисовать опять всю финальную картинку.
Чтобы этого избежать, придумали слои. JS разработчики могут на это явно влиять через will-change свойство css. А раньше для этого часто использовали transform z = 0.
В этом случае, WebKit отдаст браузеру две картинки, и он их смешает сам. С помощью skia.
В первом случае бага не будет. Потому что там будет использован код WebKit'а.
Во втором случае баг может быть.
А еще может все дело в том, что использовался не подверженный багу тип смешивания. Некоторые работали нормально :)
Но если предположить, что про что-то простое типа css свойства opacity, то тут надо немного рассказать как хром рисует веб-странички.
Предположим, что у вас есть страничка с двумя статичными полупрозрачными изображениями.
Хром ( а реально WebKit ) заранее просчитает финальную картинку, которая получается при смешивании этих двух статичных картинок и браузер уже нарисует финальную картинку.
Однако, если что-то поменяется, надо будет перерисовать опять всю финальную картинку.
Чтобы этого избежать, придумали слои. JS разработчики могут на это явно влиять через will-change свойство css. А раньше для этого часто использовали transform z = 0.
В этом случае, WebKit отдаст браузеру две картинки, и он их смешает сам. С помощью skia.
В первом случае бага не будет. Потому что там будет использован код WebKit'а.
Во втором случае баг может быть.
А еще может все дело в том, что использовался не подверженный багу тип смешивания. Некоторые работали нормально :)
На самом деле уже не webkit а blink.
Вы код хорошо изучили, прежде чем такое писать?
Если бы Агата Кристи жила в наше время, она писала бы такие детективы.
В какой версии хрома этот фикс есть?
Пока читал в голове то и дело мелькали мысли "Отлично, старый добрый Хабр, статья с деталями и сюжетом, интересно", и это правда, но концовка немного подкачала — по сути всего лишь включили оптимизацию и всем похорошело.
P.S. А то, что в 2013 году имея такие бенчмарки взяли и прошляпили — это, безусловно, странно!
P.S.S. Невольно порадовался на тему того, что "твой самый странный баг все равно не переплюнули" :)
P.S. А то, что в 2013 году имея такие бенчмарки взяли и прошляпили — это, безусловно, странно!
P.S.S. Невольно порадовался на тему того, что "твой самый странный баг все равно не переплюнули" :)
Станет ли мак-версия быстрее, как и виндовая?
Есть ли ещё простор для ускорения? Например вручную переписать на Asm этот кусок кода, добавить SSE2-4/AVX, как это делают в x264 например. Попробовать скопимилировать с помощью Intel C Compiler.
Он уже на SSE (xmm это SSE регистр). А вообще у них уже все эти реализации есть: https://code.google.com/p/chromium/codesearch#chromium/src/third_party/skia/src/core/SkOpts.cpp&l=108
Чтобы обойти проблему, разработчики решили пожертвовать скоростью? Это как понимать?
НЛО прилетело и опубликовало эту надпись здесь
На самом деле, у них есть аргументы за оптимизацию по размеру кода.
1) Размер бинарника увеличивается на 25%, а значит пользователям больше качать.
2) Меньший по размеру код более cache-friendly.
В общем, они пока решили все не оптимизировать по скорости. Можешь с ними поспорить вот тут https://bugs.chromium.org/p/chromium/issues/detail?id=548457 :)
1) Размер бинарника увеличивается на 25%, а значит пользователям больше качать.
2) Меньший по размеру код более cache-friendly.
В общем, они пока решили все не оптимизировать по скорости. Можешь с ними поспорить вот тут https://bugs.chromium.org/p/chromium/issues/detail?id=548457 :)
Как бы было замечательно если бы был оффис в Алмате!!!
Верно ли, что слои объединяются софтварно (не GPU)?
Если не секрет, расскажите почему разработчики на своей локальной машине уже используют VC++2015
а на билд-сервере сборка релиза идет на VC++ 2013?
а на билд-сервере сборка релиза идет на VC++ 2013?
Chromium тоже постепенно переходит на 2015 версию.
Вот, например, изза таких ошибок. Можно собирать и в 2010, а писать в 2015.
Если у вас большая кодобаза, то оттестировать все на уровне чуть ли каждого байта — очень тяжелая задача.
Если у вас большая кодобаза, то оттестировать все на уровне чуть ли каждого байта — очень тяжелая задача.
Это более вероятно есть баг/недочет в студии нежели ошибка при написании кода. Так что сомнительное занятие искать ТАКИЕ баги. Так, например, на днях не удалось собрать рабочий проект 13ой студией. Проект использует nlohmann/json, но из-за неполноценности реализации 11 стандарта C++ оно просто не компилируется.
Такой пространный вопрос и немножко не в тему, но может знаете, почему на Mac (со встроенной графикой) Chrome работает заметно менее плавно, чем родной Safari? Что за хитрые оптимизации заставляют работать дефолтный браузер так быстро и непрожорливо (хотя насчёт последнего начиная с какой-то версии Chrome уже не так актуально)?
Боюсь, chrome всегда будет отставать от safari. Дело в том, что chrome имеет универсальную архитектуру, которая работает на множестве платформ.
Safari же заточен под OS X. Не даром они не смогли поддерживать его под Windows и закрыли проект.
Но есть одна настройка, которая увеличивает плавность скроллинга в chrome. Надо зайти на chrome://flags и включить GPU rasterization для всех слоев:
Safari же заточен под OS X. Не даром они не смогли поддерживать его под Windows и закрыли проект.
Но есть одна настройка, которая увеличивает плавность скроллинга в chrome. Надо зайти на chrome://flags и включить GPU rasterization для всех слоев:
Я сейчас схлопочу минусов, но у меня остались вопросы:
Вообще, краткое содержание статьи мне показалось вот таким: "Мы искали баг в коде, но оказалось, что у VS 2013 кривой компилятор. А ещё мы выставили /O2 и порадовались, что скорость возросла. Конец."
Всему виной была неправильная кодогенерация в VS 2013.Что, и всё? А подробности про вырождение той ошибочно-переоптимизированной функции? А вы писали разработчикам VS 2013 о проблеме? Уверены, что в VS 2015 бага уже нет? А может он только у вас перестал проявляться?
Вообще, краткое содержание статьи мне показалось вот таким: "Мы искали баг в коде, но оказалось, что у VS 2013 кривой компилятор. А ещё мы выставили /O2 и порадовались, что скорость возросла. Конец."
ещё "Приходите к нам работать"
Почему VS ведёт себя именно так, ответить смогут только её разработчики. Баг с неправильной кодогенерацией функции SrcATop при разных целях для оптимизации был исправлен в 2015, потому что он пропал не только у нас, но и для всего Chromium (в том числе для иных ситуаций с блендингом).
НЛО прилетело и опубликовало эту надпись здесь
Ребята, сделайте уже в Linux версии поддержку H.264. Chrome (из коробки), Vivaldi (с помощью доп.модулей) позволяют смотреть. А я, как дурак, пользуюсь ЯБ, а видео смотрю в другом. Служба поддержки только следующими релизами кормят.
Может хоть тут до разработчиков достучусь?
На всякий случай Ticket#15121617250381325.
Может хоть тут до разработчиков достучусь?
На всякий случай Ticket#15121617250381325.
А когда окончательно откажутся от флеша и закопают его подальше?
Интересно, а кто-нибудь пробовал собирать при помощи gcc под windows? Насколько браузер хуже/лучше работать начинает?
Как избавиться от красного цвета в заголовке yandex browser-а? Отвлекает внимание. Беглым взглядом ощущается, как оповещение о важном событии.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
От черного прямоугольника в Яндекс.Браузере к ускорению всего Chromium