Category: технологии

nyaload

Мой серый - это зелёный

Если нарисовать пикселями шахматную доску, то она у меня окрашивается в зеленый цвет прямоугольными пятнами, положение пятен зависит от взаимного расположения элементов на далеком расстоянии на экране на той же scanline. Если залить черно-белой решёткой весь экран - то он окрашивается в четко зелёный цвет примерно соответствующий rgb=#53b053
Кто-нибудь в курсе, как называется этот баг и можно ли его поправить в мониторе (ASUS PB287Q)? Фото под катом. update: похоже что это "технология улучшения картинки" называемая в меню монитора "sharpness", но отключить её для стандартного sRGB режима невозможно.

Наткнулся на него в ходе выяснения "какое же значение гаммы используется на моем мониторе при гамма-коррекции".

* однопиксельный checker board для проверки гамма-коррекции на мониторе использовать нельзя. Чередующиеся через один пикселы не дают такого же освещения, как крупные блоки, как из-за физическо-железных проблем (пикселы не успевает поменять освещение при быстром чередовании), так и из-за железно-софтварных - баги в пост-процесс софте внутри монитора, dithering, у меня наверное что-то из этого.

* Браузеры при просмотре изменяют размер картинок, из-за чего граница между черными и белыми пикселями размывается в непредсказуемый серый. Тесты нельзя смотреть в браузере.

update: Я при измерении гаммы наткнулся на то, что браузер при ресайзе картинок размывает пиксели в непредсказуемый серый цвет без четкой границы между двумя цветами. Из-за этого у меня и получалисть неадекватные значения.

Collapse )
nyaload

багрепорты от квалифицированных пользователей

На суппорт валится много очень невнятных багов, от людей, не знающих чем отличаются браузер, интернет и сайт. С сообщениями вида "у меня не работает". Технических специалистов на разбор такого не посадишь, они свалят на другую работу.

А обученые биороботы не cмогут выделить в таком потоке жалоб подробное изложение бага с приложенным traceroute и способом воспроизведения бага. Или важное сообщение от добрых хакеров об обнаруженной уязвимости, особенно если оно слишком лаконичное и выглядит абракадаброй для биоробота, "you p0wned, XSS in user_sign cgi param"

Я думаю, что в багтрекере можно ввести "капчу" для технических специалистов, что выделить репорты от них. Не факт что они будут гарантированно вменяемыми, и наоборот, нетехнические специалисты тоже могут написать шаги для воспроизведения со скриншотами.

Примеры капчи - "чему равно (10%3 ? (71&21) : (126^13))" или "переведите 1defa из 16-ричной в десятичную систему счисления" или "команда unix для печати содержимого директории" и тд. Можно дать несколько вопросов, и засчитывать ответ на любой из них.

Вопрос про систему счисления мне нравится больше всего, кстати.
nyaload

WTF-8

Вообще я считаю что UTF-8 - это гениальное изобретение для обеспечения совместимости старых и новых программ, которое позволяет плавно переходить на юникод. Как клёво и тонко продумана сборка букв в байты, что бы работали старые программы!

Хотите что бы правильная™ технология заменила кривую, которую вы ненавидите, но которой пользуется весь мир - изобретайте такие же гениальные схемы перехода.

Обнаружил ситуацию, где незадумчивый UTF-8 ломает старый однобайтовый код: регулярные выражения вроде [а-яА-ЯёЁ] превращаются в чёрти что, через раз работающее.

Видел ещё одно место, где UTF-8 порождает баги: показать пользователю первые N символов. При этом один из русских символов разрезается ровно пополам.
В браузере выглядит так:

Это начало некого длинного текс[?]

где вместо [?] - квадратик или вопросик или т.п.

Ещё грабли, поинтересней. В cp1251 есть один неопределённый код символа, 0x98. Это соответствует второму байту буквы 'И' в UTF-8 ('\xd0\x98'). Иногда при интерпретации UTF-8 через промежуточный cp1251 происходит мистика - 'И' исчезает, заменяется на '?' и тп.

Кто ещё с чем таким сталкивался, на границе UTF-8 и однобайтовых программ?
nyaload

Денормализованые числа

Оказывается, на PC можно случайно получить сверх-маленькие (денормализованные) числа, после чего программа с расчётами может начать очень сильно тормозить. (Получить можно разными способами, например взять две матрицы поворота на 355.99998 градусов, и перемножить, где "почти нулевые" элементы могут получится денормализоваными.
Страшно, что это невозможно отключить (_control87(_DN_FLUSH, _MCW_DN) похоже ничего не делает, флажка у сопроцессора нет), может появиться в коде который ничего особенно не делает, просто камера и монстр так встали, что появилось сверх-малое число. А потом оно уползёт в AI и физику, и всё будет плохо.
Попробуйте запустить код ниже, увидете что скорость работы зависит от того, что перемножается.

Collapse )
Collapse )

updated: обнаружил в физике шариков нашего маджонга кучу таких underflow после pos + dt*velocity; и чо с этим делать - пока не очень понятно. Возможно, в вашей физике тоже полно такого, а вы об этом не знаете ;)
updated: Проверка показала, что с SSE - таже фигня.
updated: Если компилятору удаётся всё-всё засунуть в регистры, то возможно что промежуточных денормализованых чисел не будет, так как внутри регистры 80-битные. Таким образом, производительность может фантастически меняться при очень небольших правках кода. В SSE - 32 битные регистры. Поэтому на денормализованых числах FPU может работать в 100 раз быстрей, пока они в регистрах, а не в памяти. А от добавления /arch:SSE - оно начинает работать резко медленней.

Вот такой вот подарок от Intel. Как с ним бороться - непонятно. Учитывая что денормализованые числа не нужны, но отключить их нельзя.

updated:
Бинго!
/arch:SSE + _mm_setcsr(_mm_getcsr() | _MM_FLUSH_ZERO_MASK);
Источник информации:
http://softpixel.com/~cwright/programming/simd/sse.php
Intel автоматически включает этот флажок, MSVC нет.
Вроде если установить флажок DAZ (0x40), то оно подействует на FPU. У меня не получилось.