Saturday, December 25, 2010

Обрадовать PageSpeed

Ну очень короткий пост или улучшить результаты в PageSpeed ну хоть немного.

  • Включить кеширование. Если ваш случай Apache, добавляем подобную комбинацию для медиаконтента:
    Header set Cache-Control "max-age=3153600, public"
    Сжимать выдаваемый контент:
    SetOutputFilter DEFLATE
    Эти строчки желательно использовать только внутри FilesMatch, IfModule - так как сжимать картинки бесполезно, а кешировать до бесконечности html нельзя - на корень вход с параметрами в url не поставишь.
  • Объединить несколько css/js файлов в один через вызов скрипта с параметром список объединяемых скриптов/стилей. Желательно при объединении оставлять метки что откуда взято - чтобы не искать иголку в стоге сена.
  • Упаковать результаты вывода этого скрипта (желательно не полностью, а каждый файл с пометкой минимизированная версия чего представлена). Для css - мне понравилось использовать cssmin, для js - google closure compiler. Оба инструмента позволяют минимизировать на лету. Первый локально, второй можно через API удаленно. Во втором случае лучше давать исходный код, а не каким-то образом минимизированную версию.

Tuesday, December 21, 2010

Магия глубины

На прошлых выходных мне случайно попалась ссылка на интересный сайтик, который долго искал - на нем предлагаются драйвера для Windows для поддержки стереоскопичного 3d. Когда то лет 5 назад у уже видел ссылку на подобную функциональность, она включалась редактором реестра для Nvidia карт, но они ее почему-то удалили. Теперь опять в дровах она появилась, но опять для Nvidia и для топовых карт, это не является достаточным основанием, как по мне менять свои компьютер с ATI видеокартой. Вот теперь эту функциональность можно посмотреть на любой видео карте. Правда некоторые игры имеют возможность самостоятельно создавать картинку с искажениями цветов нужные для анаглифных очков, но хотелось везде и сейчас.

И вот на какие мысли это меня натолкуно:

На уровне драйверов это приводит в теории к двукратному увеличению нагрузки для видеокарты, так как просчитывается отдельные изображения для каждого глаза. Но при этом очень большое количество данных просто пересчитывается впустую, так как для дальних планов(где различия из-за расстояния между глазами ниже пикселя) данные расчеты выполняются в общем-то в пустую. На уровне игрового движка в теории это можно минимизировать - просчитать какие объекты видны обоим глазам (множество того что они видят - почти полностью одно и тоже).

Это в принципе равнозначно тому, что у обоих кадров подобны буферы глубины кроме близко расположенных объектов. И если генерировать сначала буфер глубины для далеких объектов, там где разница в отображении для разных глаз меньше пикселя, то загружая эти данные в буфер глубины мы резко сокращаем количество расчетов цвета и для точек, так как все дальние точки уже учтены на этом буфере. Или можно брать кадр с расстоянием до точек для одного глаза и убирая все точки ближе определенного минимума- мы получим исходные данные для второго глаза. Правда можно еще учитывая данные о расстоянии немного сдвигать изображения для каждого глаза - но это получается какая-то косоглазая глубина.

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

На уровне игрового движка можно сделать карты глубины для больших расстояний для всех круговых углов обзора и использовать ее как тестуру по границам доступного в течении ближайшего пространства, тогда можно подправляя при приближении к этим границам, добиться возможности место расчета далеких объектов просто поставлять большую текстуру - думаю это снимает проблемы больших пространств, где нужно пересчитать все что может попасть в область видимости. Подобные текстуры, как я знаю, используются в Quake2 для неба, но они статичны. Я думаю это резко сокращает количество полигонов.

Может так и делают и я что-то упустил?

Saturday, December 4, 2010

Применение смартфонов с точскрином

Так как они не могут пока конкурировать с обычными мобильными телефонами по времени жизни без зарядки. Обычные мобильные телефоны живут где-то ближе к неделе(или это у меня они так долго выдерживали) с точскрином с нормальными характеристиками и внешним видом живут где-то 2 дня максимум.

Я подумал их же можно использовать вместо мышки - такой высоко технологичной и дорогой. Они все имеют какое-то подобие usb порта и теоретически можно создать приложение которое будет эмулировать протокол мышки для компьютера и экран можно использовать как подобие точпада с возможностью отображение области под указателем мышки и дополнительной информации - например управление через поворот относительно сторон света и 3d управление через акселерометры и gps.

Ядро 2.36.1 + Ubuntu

Поставил где-то месяц назад(может и больше) себе новое ядро - все работает нормально, ну почти. Если не запускать piglit, то никаких артефактов ввиде переключения в полностью черный экран или отсутствия реакции на клики мышкой(но она еще может двигается) и тому подобное нет. Ранее эти спецэффекты на стандартном ядре появлялись в самый не подходящий момент.

Sunday, November 7, 2010

Восмеричность(octal)

Пример почти рабочего кода с иногда неожиданным результатом:

Язык

Код

Результат

php:

echo (int)08;

0

javascript:

alert(parseInt("08"));

0

c/c++:

int main() { printf("%d\n", 08); }

error: invalid digit "8" in octal constant

python:

print 08

SyntaxError: invalid token

Erlang:

B = 08.

8

Tuesday, November 2, 2010

Видео с конференции Yandex

Конференция проходила 1 октября.

Наиболее интересное по моему мнению:
  1. 'Базовые оптимизации' Петр Попов - Краткие описания оптимизации алгоритмов в основном хранения индексов.
  2. 'Построение системы видеокоммуникаций для большого числа пользователей в сети Интернет' Вячеслав Борилин - Текущее состояние передачи видео в конференциях, какие существуют проблемы.
  3. 'Танки в Лунапарке' Андрей Кузьмичев - Просто интересный(веселый) доклад.
  4. 'Веб-сервер Phantom' Влад Селиверстов - Описание архитектуры их вебсервера, легковесные потоки и состояния - но на С++, а не на экзотических языках. Тестовые данные несколько сомнительны, но как доказательство что можно и без экзотики создать быстрое решение.
  5. 'Как мы охотимся на гонки (data races)' Константин Серебряный - Теория определения гонок и как они их выявляют, инструменты.

Sunday, October 31, 2010

Компиляция новой прошивки для D-Link 2650

По пунктам:
  1. Загружаем и устанавливаем в виртуальной машине Fedora 9.
  2. Загружаем исходные коды прошивки.
  3. Распаковываем и запускаем(в виртуальной машине) install.sh на все вопросы отвечаем утвердительно.
  4. В результате в систему устанавливаются crosstools для mips(/opt/toolchanins).
  5. Заходим в /opt/DLink DSL-2650U и пишем make PROFILE=DSL-2650U
  6. Все первая прошивка готова, она будет собрана в images
  7. Теперь идем в userapps/opensource/busybox
  8. Копируем brcm.config в .config, если еще его нет
  9. Запускаем make menuconfig выбираем нужные нам программы(ls, cp) так в стандартной прошивке их нет. Особо экономить на включении не нужно там оригинальная прошивка немного больше 4мегабайт и вполне хватить места еще под пару программок в оставшемся свободном месте 8 мегабайтной внутренней флешки.
  10. Сохраняем полученный .config в targets/DSL-2650U/brcm.config
  11. Пересобираем прошивку
  12. Все - прошиваем и проверяем.

Возможно можно использовать другую версию, но на 9 все работает. Для того чтобы использовать на других нужно пересобирать crosstools и проще просто поставить виртуальную машину чтобы не морочить голову с версиями. В прошивке используется старое ядро 2.6.9 и старый busybox(даже не стабильная версия, а 1.0.0-rc3). Обновить ядро наверное не очень получиться так как часть модулей, если посмотреть по структуре директорий, уже в бинарном виде.

Для экспериментов можно использовать программы записанные на USB флешку, так как при монтирование разрешено запускать программы с флешки и они вполне работают.

Дополнительную информацию можно посмотреть здесь и инструкция по прошивке OpenWRT на него.