![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
Получилось круче, чем я ожидал. fullscreen 2560x1440 fade-in/out с примесью шума шпарит на 60fps 2560x1440 с 62% утилизацией CPU и нулём спецусилий по оптимизации (кроме использования texture.update).
Всё остальное в SDL офигенно. Нужен fullscreen? Фигак. Нужно курсор убрать? Фигак. Нужно узнать разрешение этого самого fullscreen? Фигак. Всё что нужно и без доп. заморочек. Я пока не до конца понимаю необходимость разделения между window и canvas, но это мелочь.
Вот код демки: https://github.com/amarao/sdl_random
В целом я чувствую нереальное освобождение после боли с недокументированным piston'ом в котором "texture context" это мистическая фигня, которая что-то делает, но что именно не разобрать.
В целом, в equart примерно треть накрученного кода была связана с тем, что я не мог просто и дёшего копировать байты в текстуры. Можно было 'draw', что было крайне далеко от "вот тебе массив u8, это новое содержимое текстуры". (Возможно, тут ещё разница между старым процом и новым...), в SDL это очень просто.
Сейчас я засяду за многопоточный диспетчер "рисования", и мне придётся снова решить как правильно рисовать. Видимо, всё-таки слать changes.
О чём речь?
У меня есть тред, задача которого рисовать и обрабатывать события (ресайз, потенциально "стрелочки" по картинке и т.д.). Я хочу, чтобы этот тред был 100% отзывчивым.
Ещё есть то, что я рисую - это график уравнения или функции. Функция может считаться очень медленно и совершенно нормально, если часть точек будет появляться со временем (вплоть до минут). Задача рассчёта полностью и легко параллелится на треды, так что можно утилизовать все ядра.
Возникает два подхода к тому, как эти треды сообщают о нарисованном:
Они раз в N времени пересылают в основной тред свой кусок битмапа целиком, все зависимости от того, что было посчитанно.
Либо, они шлют поток команд на рисование (т.е. список точек и их цветов).
... задача ресайза требует "группировки" данных от разных тредов.
Возможно, мне удастся засунуть в один тред процесс "рисования" по данным, а треды будут просто эти данные считать. Я глубоко впечатлён seqlock'ами в ядре (кто не знает - lockless метод доступа к шареным между тредами данным, позволяющий читать и писать одновременно, при условии, что запись происходит не сильно часто), так что можно с ними поиграть тоже.
UPD: Ещё, вся моя демка после компиляции - 350к (после strip). Это, конечно, не 64к com-файлы, но и не многие мегабайты.
... продолжаю разглядывать ассемблер...
if frames % 2 == 0 {
test al, 1
jne .LBB24_53
Всё остальное в SDL офигенно. Нужен fullscreen? Фигак. Нужно курсор убрать? Фигак. Нужно узнать разрешение этого самого fullscreen? Фигак. Всё что нужно и без доп. заморочек. Я пока не до конца понимаю необходимость разделения между window и canvas, но это мелочь.
Вот код демки: https://github.com/amarao/sdl_random
В целом я чувствую нереальное освобождение после боли с недокументированным piston'ом в котором "texture context" это мистическая фигня, которая что-то делает, но что именно не разобрать.
В целом, в equart примерно треть накрученного кода была связана с тем, что я не мог просто и дёшего копировать байты в текстуры. Можно было 'draw', что было крайне далеко от "вот тебе массив u8, это новое содержимое текстуры". (Возможно, тут ещё разница между старым процом и новым...), в SDL это очень просто.
Сейчас я засяду за многопоточный диспетчер "рисования", и мне придётся снова решить как правильно рисовать. Видимо, всё-таки слать changes.
О чём речь?
У меня есть тред, задача которого рисовать и обрабатывать события (ресайз, потенциально "стрелочки" по картинке и т.д.). Я хочу, чтобы этот тред был 100% отзывчивым.
Ещё есть то, что я рисую - это график уравнения или функции. Функция может считаться очень медленно и совершенно нормально, если часть точек будет появляться со временем (вплоть до минут). Задача рассчёта полностью и легко параллелится на треды, так что можно утилизовать все ядра.
Возникает два подхода к тому, как эти треды сообщают о нарисованном:
Они раз в N времени пересылают в основной тред свой кусок битмапа целиком, все зависимости от того, что было посчитанно.
Либо, они шлют поток команд на рисование (т.е. список точек и их цветов).
... задача ресайза требует "группировки" данных от разных тредов.
Возможно, мне удастся засунуть в один тред процесс "рисования" по данным, а треды будут просто эти данные считать. Я глубоко впечатлён seqlock'ами в ядре (кто не знает - lockless метод доступа к шареным между тредами данным, позволяющий читать и писать одновременно, при условии, что запись происходит не сильно часто), так что можно с ними поиграть тоже.
UPD: Ещё, вся моя демка после компиляции - 350к (после strip). Это, конечно, не 64к com-файлы, но и не многие мегабайты.
... продолжаю разглядывать ассемблер...
if frames % 2 == 0 {
test al, 1
jne .LBB24_53
