Программирование

RawDigger 0.9.20 RC4

Господа фотографы, прежде всего фовеонщики!

Выпущен очередной релиз кандидат RawDigger 0.9.20:

Основное изменение: поддержаны (в LibRaw) уменьшенные варианты RAW камер Sigma DPx Merrill и SD1. Для "среднего" размера, который с точки зрения Сигмы ~3300x2200 показывается его истинный размер (4800x1600), при этом, как и для других форматов с "неквадратными пикселями", RGB-рендеринг выключен.

Помимо этого, исправлена ошибка в разборе выдачи exiftool.

Прочие изменения - это на самом деле изменения в LibRaw:

  • Поддержаны DNG без тега Compression (считаются uncompressed)
  • Поддержаны новые камеры: Panasonic GM1, Sony A7 и A7R (хотя в списке About - Supported Cameras их пока нет, но к релизу будут)

LibRaw 0.16 Alpha2

Тем временем, зарелизилась LibRaw 0.16 Alpha2.

Основные изменения касаются Фовеонов:

  • LibRaw теперь знает размер черной рамки на всех фовеоновских камерах.
  • Для SD1 и всех Merrill-ов есть приемлемый цветовой профиль.
  • Для DPxx (pre-Merrill) цветовой профиль весьма приблизительный.
  • Исправлен memory leak в используемой библиотеке x3f-tools.
Но и для остальных камер произошли заметные изменения:

Про Mac OS X и совместимость (и ленивый линкер)

По случаю выхода XCode5 взялся я проверять, а что у этой штуки с backward compatibility, не сломалось ли чего, будет ли работать на Mac OS 10.5, к примеру...

И, надо сказать, результаты меня расстроили (помимо необъяснимой проблемы с VMWare

Для начала я наткнулся на широко известную проблему с ___bzero, на которую все кто мог уже наступили:

dyld: lazy symbol binding failed: Symbol not found: ___bzero
  Referenced from: ....
  Expected in: /usr/lib/libSystem.B.dylib

Лечение нашлось быстро: -mmacosx-version-min=10.5 эту проблему лечит.

Дальше стало хуже:

posix_memalign(), если попросить у нее мегабайтиков 100 (меньше не пробовал), на 10.5 не справляется. Причем, сайт developer.apple.com полагает, что эта функция появилась только в 10.6. Удивительное рядом - она вызывается, правда результат ее вызова неудовлетворительный (в коде поведение одинаковое что при ейной ошибке, что при исполнении без ошибок но и отсутствии аллокации, в детали не вдавался).

Сделал K (меньше N) экспериментов, убедился что на 10.5 malloc (у меня!) возвращает всегда 16-byte aligned, временно сделал затычку (ну и написал в TODO, что надо бы анонимный mmap() в это место).

Варез начал запускаться и местами работать. А местами - падать (не при запуске, в процессе). Потому что нашлось сразу две новые фишки:

  • __ZSt16__ostream_insertIcSt11char_traitsIcEERSt13basic_ostreamIT_T0_ES6_PKS3_l (или, если человеческим языком, то std::basic_ostream<char, std::char_traits<char> >& std::__ostream_insert<char, std::char_traits<char> >(std::basic_ostream<char, std::char_traits<char> >&, char const*, long)). Каковой __ostream_insert на самом деле используется в std::string, а std::string - в std::runtime_error.
  • У этой самой макоси - ленивая линковка, поэтому падает оно не при запуске, со словами "символ не нашелся", а на рантайме (weak linking).

Конкретную проблему я порешал, запретив использование RawSpeed на 10.5 (и posix_memalign() и __ostream::insert - обе проблемы были в RawSpeed), но осадок остался.

Дивлюсь я на небо, та думку гадаю:

  1. (деструктивная часть): "Программа запускается и как-то работает" в этой вашей Макоси не означает ничего. Мы просто могли не дойти до места, где потребуется (и не найдется) нужный символ. Тестирование обычным способом становится веселым.
  2. (конструктивная): а как бы проверить, что все символы, которые у моей софтины (и всех используемых библиотек вообще-то) в действительности присутствуют? Погуглил все известные слова, не нашел.

LibRaw 0.16 (Alpha1)

Мастер-версия LibRaw получила официальный номер 0.16-Alpha1 и доступна для скачивания.

Это означает, что все глобальные идеи по развитию закончились (на ближайшее время) и нестабильности API - не ожидается. Сама по себе 0.16 достаточно стабильна, в RawDigger используется именно эта версия (и всегда используется "девелоперская", а не "стабильная"), проблем не было.

С полным списком изменений относительно версии 0.15 можно ознакомиться в changelog, ниже откомментированы основные места:

Не проходите мимо!

Нежно любимый всеми Agner Fog пишет

The optimization manuals at www.agner.org/optimize/#manuals have now been updated. The most important additions are:

AMD Piledriver and Jaguar processors are now described in the microarchitecture manual and the instruction tables.
Intel Ivy Bridge and Haswell processors are now described in the microarchitecture manual and the instruction tables.
The micro-op cache of Intel processors is analyzed in more detail
The assembly manual has more information on the AVX2 instruction set.

Уже качаю, будет чтение на ночь

Заодно от там AMD Pilediver обижает

Supports fused multiply-and-add instructions in both the FMA3 and FMA4 form. FMA3 is compatible with Intel processors. See Wikipedia for a discussion of the incompatibility between these instruction sets.

The throughput of FMA3 instructions is only half as much as the throughput of FMA4 instructions, even though they are doing exactly the same calculations.

Memory writes with the 256-bit AVX registers are exceptionally slow. The measured throughput is 5 - 6 times slower than on the previous model (Bulldozer), and 8 - 9 times slower than two 128-bit writes. No explanation for this has been found. This design flaw is likelty to negate any advantage of using the AVX instruction set.

The VMASKMOVPS instruction with a memory source operand takes more than 300 clock cycles on the Jaguar when the mask is zero, in which case the instruction should do nothing. This appears to be a design flaw. This instruction is not very common, though.

Таки что, детектить CPU и запрещать AVX для этих горшков?

RawDigger 0.9.19 RC1

Граждане фотографы!

А потестируйте, кому не лень, RawDigger 0.9.19 уже не надо, вышел релиз.

Это косметический релиз, который не вносит ничего принципиально нового, но лечит проблемы и доделывает недоделки предыдущих версий:

  • Экспорт всех цветовых байеровских RAW-данных в одноканальный (grayscale) TIFF.
    В первую очередь этот режим предназначен для использования с черно-белыми камерами, изготовленными путем смытия светофильтров (maxmax.com и другие).
  • Параметры Selection Grid запоминаются между перезапусками программы.
  • Можно выбрать набор фолдеров, показываемых в левой колонке в диалогах сохранения файлов (экспорт RAW-данных, сохранение таблицы замеров).
    Регулируется через Preferences - Misc Options - Sidebar folders in Save dialogs
    Данная регулировка появилась в связи с жалобами: если запоминать список использованного и в нем окажется медленный или отключенный диск (неработающие сетевые диски и т.п.), то диалог сохранения открывается черезвычайно медленно.
  • Поля CGATS-файлов в которых могут быть пробелы (имя файла, Maker/Model камеры) выводятся в одинарных кавычках
  • Возможен экспорт RAW/RGB данных в Uncompressed TIFF. Для сжатого TIFF улучшено сжатие.
  • При выводе чисел с плавающей точкой везде выводится не менее 4 значащих цифр (исключение: процент пере/недоэкспонированных пикселов, там 3 цифры)
  • Появилась настройка Preferences - Misc Options - Disable check for updates at startup
    Если она включена, RawDigger не обращается к сайту с апдейтами на старте. скрипт noCheckUpdates.reg (.sh в Mac-версии) удален из дистрибутива.
  • Обновлена LibRaw, добавлена поддержка новых камер: Panasonic LF1,GX7, Fujifilm X-M1, Canon EOS 70D, Sony RX100II и RX1R, Olympus E-P5

При отсутствии противопоказаний, эта же версия выйдет в начале следующей недели как "релиз", английская версия выйдет тогда же. Пожалуйста, не тревожьте англоязычных пользователей раньше времени анонсами.

Узок их круг, страшно далеки они от народа

Вот берем Qt 5.1, тащим на Mac OS X 10.7 (так сложилось, это моя девелоперская машина), собираем согласно инструкции.

Далее собираем приложение с этой Qt, деплоим его тоже по инструкции, несем на Mac OS X 10.6 и получаем, получаем... сюрприз:
Неработающее приложение!

То что пишут в mailing lists я приличными словами назвать не могу.

Но только там, в этих рассылках, удается понять, что надо ./configure -no-c++11 и собирать без вебкита (впрочем, у меня деплоится без вебкита т.е. мог бы и с ним собирать). Если же не собирать, а брать готовые библиотеки с сайта Qt, то счастья и вовсе не будет.

И ладно бы речь шла о какой-то старой и никому не нужной версии Mac OS X. Гугление нашло такой вот график:

Взято отсюда, это, конечно, Апрель-2013, но я не думаю, что за 4 месяца что-то сильно поменялось (а у фотографов, по ощущениям, доля 10.6 еще выше). И я бы даже про 10.5 бы не забывал, если бы мог...

А, да, раньше в Qt-шном ./configure был ключик -no-webkit. Как вы думаете, как сейчас собрать Qt без вебкита?

RawDigger 0.9.18 RC1

Граждане фотографы!

А потестируйте пожалуйста Release Candidate следующей версии RawDigger:

Всем спасибо, вышла 0.9.18 без лишних букв.

Список изменений в этой версии короткий, однако изменения существенные. От менее значительных к более:

  1. 9 новых камер (см. Changelog)
  2. В CGATS-файлы пишется дополнительная информация (об использованных коэффициентах ББ, о множителе масштабирования, о максимумах данных), сами CGATS-файлы еще более приближены к стандарту.
  3. Можно делать RGB Rendering "как видит камера" (т.е. без наложения камерного профиля, конвертирующего в sRGB)

    Настройка Preferences - Display Options - Display RGB Render in RAW colors

    Если брать какой-то стандартный объект, скажем Color Checker, то чем менее насыщенными будут цвета в этом режиме, тем "шире фильтры". Вероятно, можно придумать какую-то метрику, которая будет это описывать.

    Если вы включите эту галку для 4-канальных не-RGBG RAW, то у вас пропадет RGB-rendering на экране (потому что как на RGB-экране посмотреть CMYG или там RGBE), но результат рендеринга можно будет экспортировать в 4-канальный TIFF и затем рассмотреть его в Фотошопе (который, правда, воспримет этот TIFF как CMYK :).

  4. Canon sRAW-файлы можно рассматривать "как они на самом деле устроены":

    В sRAW записаны данные в формате YCbCr, стандартная процедура декодирования (в LibRaw/RawSpeed) сразу конвертирует их в RGB и всего безумия, которое там творится, не видно.

    В новой версии RawDigger это преобразование можно отключить настройкой:

    Preferences - Data Processing - Show YCbCr data for Canon sRAW files

    И рассмотреть YCbCr данные как они есть.

    Очень поучительное зрелище, отвращает от этого формата надолго.

  5. Экспорт RAW/RGB-render данных в TIFF-файл.

    Menu - File - Export TIFF

    Несмотря на то, что эта штука во многом дублирует имеющиеся в LibRaw утилиты командной строки (dcraw_emu, 4channels, unprocessed_raw), пользоваться ею через GUI оказалось удобно.

На последней штуке остановлюсь подробнее:

Об одном известном макроассемблере

Вот есть такая dcraw.c, а в ней есть такие вот две строчки кода:
  unsigned int *data,pad[128],p;
  ...
  while (len--)
      *data++ ^= pad[p++ & 127] = pad[(p+1) & 127] ^ pad[(p+65) & 127];
И все было ничего в gcc 2.x...4.7, а вот 4.8 компилирует это место неправильно.

Я даже посмотрел генерируемые ассемблеры, увидел что разные, но за 30 секунд не разобрался (потому что константы 1 и 65 у 4.8 становятся 2 и 66 и надо внимательно смотреть в каком порядке там что инкрементится).

Переписал так:

  while (len--)
    {
      *data++ ^= pad[p & 127] = pad[(p+1) & 127] ^ pad[(p+65) & 127];
      p++;    
    }
Помогло. Но осадок - остался.

Вопросов у меня, собственно, два три:

  1. Куды жаловаться на gcc Действительно UB? Но ведь есть такое естественное знание, что сначала вычисление правой части, а потом уже присваивание к левой. Это ж поимеет в куче мест.
  2. Правильно ли я понимаю, что пересечение множеств "Linux с пакетами собранными 4.8" и "Фотограф в RAW" крайне мало отличается от пустого множества?
  3. А не отличается ли это место в C и в C++?
P.S. Помимо баланса белого, который поминается в в багрепорте, отваливается еще и декодирование файлов с Sony DSC-V3, Sony F828 и, возможно, еще каких-то (у меня таблички декодер - камера нету)

P.P.S. Если отвалится какая-нибудь криптуха или там MPEG-декодер - я совершенно не удивлюсь.

RawDigger 0.9.16 RC2: поддержка небайеровских RAW

Граждане фотографы!

Особенно те из вас, кто не уехал на праздники.

А вот опробуйте свежий RawDigger 0.9.16 RC2:

Крупные изменения

  1. Поддержка не-байеровских RAW: sRAW/mRAW, linear DNG, некоторые виды файлов с multishot MF backs.
    Поддержки фовеона в данной версии нет, запланировано на 0.9.17
    Для YCC-кодированных файлов (sRAW, Kodak YCC) показываются RAW-значения после преобразования в RGB (это преобразование делается LibRaw/RawSpeed на этапе декодирования RAW).
  2. Поддержка DNG с lossy-компрессией (сохраненные Lightroom 4.x)
  3. Правильная работа с не-4-цветными RAW: нельзя выбрать для показа несуществующий канал, в сохраненных таблицах правильное число столбцов (нет столбцов с нулями) и т.п.

Мелкие изменения и багфиксы

  • Сохранение CGATS:
    • В первую строчку пишется CGATS.17, чтобы новые версии Argyll были счастливы
    • Элементы цветовой таблицы можно именовать "с ведущим нулем" (A01 вместо А1), для совместимости с уже существующими стандартными таблицами замеров стандартных мишеней.
  • Исправлено (возможное) падение под Mac OS X, если надропать сразу много файлов.
  • Окончательно (хочется надеяться) исправлен показ передержки/недодержки для файлов, использующих полный 16-битный диапазон значений.

Мне было бы приятно, если бы эту штуку потестировали бы, особенно на sRAW/mRAW от разных кэнонов (оказалось, что не так просто найти таких примеров).

Не было у бабы забот.....

И привезли ей (т.е. мне) компьютеров китайских:

Извините за качество, телефоном.

Судя по рассказам, тот секс, который был с Linux в начале 90-х - жалкое подобие того секса, который происходит с этими палочками сейчас.

Q: Qt MousePressEvent

Я пока не очень опытный Qt хакер, поэтому спрошу.

Вот есть QGraphicsView, у которого есть стандартная функциональность - можно по нажатию левой кнопки мыши скроллить это самое View (setDragMode(QGraphicsView::ScrollHandDrag)).

А теперь, допустим, я хочу делать то же самое не по левой кнопке, а еще по какой-то, скажем по Shift+правая кнопка.

Могу ли я сделать так:

class myView: public QGraphicsView {
  void mousePressEvent(QMouseEvent *e) {
      if(e->button() == Qt::RightButton && (e->modifiers() & Qt::ShiftModifier)) {
        QMouseEvent simulatedDrag(e->type(),e->pos(),e->globalPos(),Qt::LeftButton,
                                 Qt::LeftButton,Qt::NoModifier);
        QGraphicsView::mousePressEvent(&simulatedDrag);
        e->accept();
       }      
   }
};
(ну и аналогично с mouseReleaseEvent - проверить что отпустили нужную кнопку и фигануть симулированный эвент в базовый класс.

Вопрос: я что-то при этом сломаю?

Нет, я попробовал и вроде все работает, но вдруг я чего-то не заметил?

О синтаксическом сахаре

Есть у меня некий варез и в этом варезе настраивается клавиатурная раскладка (т.е. каждому действию можно сопоставить произвольный клавиатурный аккорд).

В потрохах редактора раскладок содержится примерно такой вот код (по смыслу):

// Инициализация
QKeySequence key; // Текущий shortcut
QPushButton *keybutton = new QPushButton(key.toStrin());
keybutton->setProperty("shortcut",key.toString());
..
// Обработка нажатой кнопки в слоте, который зовется по нажатию:
QObject *sender = QObject::sender();
QString shortcut = sender->property("shortcut").toString(); // Какую кнопку на самом деле нажали
И все работало прекрасно, пока я не решил сделать в этом же месте еще и обработку кнопок мыши, чтобы действие можно было бы назначить и на, к примеру, Ctrl-Shift-RightClick.

Меняем код немножко:

My_KeyOrMouse key; // My_KeyOrMouse - generic-контейнер для QKeySequence или мышиных событий
QPushButton *keybutton = new QPushButton(key.toString()); // Строковое представление есть
keybutton->setProperty("shortcut",key.toString());
..
// Обработка нажатой кнопки в слоте, который зовется по нажатию:
QObject *sender = QObject::sender();
QString shortcut = sender->property("shortcut").toString();
И тут начинаются чудеса: для кнопок все продолжает работать, а для мышиных кнопок - нет, sender->property(..).toString(); возвращает пустую строку.

Разгадка оказалась проста:

Win32 и C++ library

А верно ли я понимаю, что если у меня есть функция с таким вот прототипом (примерно)

Someclass::somefunc(std::string *);
То если я ея вынесу в DLL, а у себя в коде напишу
std::string foo("blabla");
Someclass bar;
bar(&foo);
То в какой-то момент это меня обязательно поимеет? По той простой причине, что Someclass.dll живет с одним C++-рантаймом, а мой код - с другим?

P.S. Если че, это не я так пишу. Adobe XMP SDK, мать его за ногу, а в нем

SXMPMeta::SerializeToBuffer(string* buffer, some_enum flags);
Как я посмотрел, все разумные люди ему делают С-шный враппер, но мне надо то два раза по 6 строчек и делать враппер противно.

RawDigger 0.9.15 (RC1): удобное профилирование камер

Граждане фотографы!

В очередной раз предлагаю потестировать Release Candidate свежего RawDigger:

В версии 0.9.14 в RawDigger была добавлена удобная работа с цветовыми шкалами, но результат этой работы выводился в виде усредненных RAW-значений: в диапазоне значений камеры, без баланса белого, без гамма-коррекции. Как следствие, для нормального использования в программах профилирования эти данные приходилось предварительно обрабатывать в Excel или подобных программах: накладывать ББ, масштабировать, гамма-корректировать.

Версия 0.9.15 исправляет этот недостаток, теперь можно получить CGATS-файлы, пригодные для прямого скармливания в Profile Maker, Argyll и подобные программы.

Кроме этого, 0.9.15 умеет корректировать неравномерность освещения мишени.

Подробности:

Q: /3GB switch и карта памяти

Вот есть у меня RawDigger в его 32-битной виндовой ипостаси.

И есть одна и та же виндовая машина, Win7-64 бита.

Линкую с поддержкой/без поддержки /3GB (/LARGEADDRESSAWARE у линкера) и скармливаю один и тот же файл (80-мегапиксельный с задника). На 64-битной винде программе с поддержкой /3GB дадут 4GB, а без такой поддержки - 2Gb.

Дальше начинаю собирать и так и сяк и вижу, что вариант без поддержки 3GB получает от системы по рогам когда потребление памяти у него (Peak Working Set по таск-менеджеру/процесс-эксплореру) вовсе не 2Gb, а ~1.1. А вариант с поддержкой - дорастает до 1.2Gb (многовато, да, но примерно столько и расходуется на всякие глупости, чтобы при смене настроек не перечитывать файл).

Вопрос: а чем-то можно в винде посмотреть "использованное адресное пространство"? Ну то есть я догадываюсь, что ~800M пропали по причине фрагментации, а как-то можно мэпу хипа глянуть?

Может есть какой-то правильный маллок, которому можно пометить аллоцированное (именами, или по номерам строк в файле), а он потом карту нарисует?

Потому что сдается мне, что 80Mpix можно и без /3GB смотреть, надо только аллокации в правильном порядке делать.

Про статический анализ С++

Тут меня навели на Coverity SCAN, которую дают помацать опенсорсным проектам на халяву.

Ну я посабмитил туда LibRaw, сегодня пустили, результаты оказались удивительными:

107 предупреждений, из них где-то треть - с High Impact.

Из High Impact:

  • Штук 10 в Microsoft STL (я самбитил виндовую сборку)
  • Еще какое-то количество такого примерно вида:
     int variable;
     if(layout==Layout1) variable=value1;
     if(layout==Layout2) variable=value2;
    И на это дается предупреждение, дескать неаккуратненько, не инициализированная переменная. Я с ним согласен по общим ощущениям, так не надо делать. Но в реальной жизни бывает два вида layout - и это явно прописано в вызывающем коде. Т.е. у машинки достаточно данных, чтобы сообразить, что это не 'High impact', а просто неаккуратненько.
  • Некоторое количество предупреждений, дескать unsigned short при расширении до 32-64 бит может больно укусить. С этим я не хочу спорить - формально машинка права, а по факту в этих unsigned short живут размеры картинки и до 32767 они в ближайшие годы не дорастут.

    Т.е. опять, фиксить не надо - в случае данной предметной области.

  • Все остальные найденные 'High Impact' проблемы - это просто ложные срабатывания. Т.е. код, согласен, не идеальный (видели бы вы этот код из dcraw !), но все найденное - не является ошибкой.

    В частности, любимый коффиновский метод проверки диапазона значений 0..N одним действием машинка просто не чует:

    int var=-1;
    if(bla-bla) { var = some_non_negative_value; }
    if( (unsigned)var < 5) // => это проверяет на диапазон 0..4
    Я сам ТАК не пишу, но читаю и считаю что прием, как минимум, надо знать и в чужих исходниках распознавать.

    Но кроме этих ложных срабатываний - еще куча других, тоже ложных.

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

Вопросы у меня такие:

  • А кто-нибудь использует статический анализ по смыслу (а не из соображений, что CTO/PM велел, чтобы предупреждений не было, вот мы и дуем на воду)?
  • А в компактных проектах, которые ведутся очень небольшим количеством опытных девелоперов? (я опять же понимаю, что в большом проекте статический анализатор наводит орднунг, от которого польза..)
  • И если на оба вопроса ответ "да" - то есть ли польза от потраченного времени? Ну вот если потрачу я сейчас час-другой на расстановку галок "это - не ошибка, а специально так сделано" - стоит ли ожидать пользу в дальнейшем?

Про отладку в Win32/Visual Studio 2010

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

  • Запускаю просто бинарь, подаю проблемные данные - падает.
  • Запускаю тот же самый бинарь (релизный, без пересборки) из Visual Studio (2010) - работает.

Падает оно в buffer overrun, в одном и том же месте (внутри ntdll, а туда попадает из malloc, которому дали неверные данные в результате более раннего overrun).

Вопрос: как такое может быть? Visual Studio при отладке релизных бинарников подпихивает другие DLL? Или вообще что?

Update подниму из комментов эту вот ссылку: http://blogs.msdn.com/b/oldnewthing/archive/2013/01/03/10381959.aspx

В моем случае это оказалось ОНО. Т.е. _NO_DEBUG_HEAP - и сразу счастье. В том смысле, что ошибка появилась и под отладчиком.

RawDigger 0.9.14

Вышел RawDigger 0.9.14. От Release Candidate ничем (кроме номера версии) не отличается. Перепост и распространение - приветствуются.

Немого кино уже нет, звукового кино еще нет....

Вот есть некая программа, которая активно использует OpenGL.

Используется Qt5 и все было бы хорошо, если бы не моментики:

  • QWidget::showFullScreen() не работает на Mac OS X 10.6
  • Курсор в форме руки - остается таковым и при выносе мыши за окно программы (тоже на Mac, на винде все нормально).
По первому случаю - я засабмитил баг, прямо вот 1-го января. Но он все еще в состоянии Not Evaluated (что неудивительно, если посмотреть на график количества багов в Qt за последние 30 дней). По второму - вроде нашел багрепорт, им как-то занимаются.

Ладно, у меня ничего специфического от Qt5 нету, собираем все то же самое на Qt 4.8.4. Работает (ну, пришлось поменять QOpenGLProgram на QGLProgram и так далее в том же духе, но изменений - мало).

Но:

На операционках, запущенных под VMWare (и Windows и Mac) - валится в QGLFunctions::initializeGLFunctions(), судя по отладчику - GL-контекст в этом месте нехорош, дальше не разбирался).

При этом, Qt5 на этих же виртуальных машинах - работает, возможностей тамошнего OpenGL вполне хватает.

На настоящих железных компьютерах с настоящим OpenGL - версия собранная с 4.8 - работает, а неприятные мне баги на маках - отсутствуют. Фулскрин работает, курсор меняет форму как надо.

Ну и как с ними жить? Баги Qt5 явно быстро не починят. Багу Qt 4.8 - скорее всего тоже не починят. Не, ну я могу gl....() сам порезолвить, но обидно же ж.

Pages

Subscribe to Программирование