SDL 2.0.7

Попробуй его использовать

Уже. Я всегда при изменении разрешения на дисплее размещаю на нем окно. При этом код SDL 1.2 и 2 работает идентично. Никаких искажений не видно, соотношение размера окна и fbo одинаковое.

А можно где-то скачать и посмотреть как оно работает? Может я просто doing it wrong?

Зачем изменять разрешение?
Потому что растягивание картинки через FBO тормозит
Зачем растягивать картинку через FBO?
Потому что нельзя сменить разрешение

Немного непонятная логика получается

Ещё раз повторюсь, функции SDL например, при масштабировании картинки, просто меняют координаты вершин соответствующим образом

То же самое можно сделать и в вершинном шейдере при желании

Зачем использовать FBO?

Можно, закоммитил в то что у меня выложено. Раскомментируй этот блок https://github.com/lieff/lvg/blob/master/platform/platform_sdl.c#L157

Я тут немного поэкспериментировал. На убунте у меня все разрешения работают нормально, за исключением 640х480 - на нем всплывает то что ты говоришь, но, всплывает и на SDL 1.2. На opensuse все разрешения норм.

Баг в убунте похоже связан с тем, что в настройках системы у дисплея нет 640х480 и его нельзя установить. А SDL это разрешение почему то сообщает, при этом оно видимо вместо реальной смены пытается как-то эмулировать и все слетает, даже обратно уже не переключается, если выйти в десктоп он уже нормально не функционирует. Это какой-то баг X11 или еще чего то.

сложно сказать, уже и не вспомню. Помню только, что у qt тогда lgpl еще не было, одна из причин костылять свой лисапед. Вторая - кросплатформенность.

http://www.2-byte.ru/images/screenshots/01.gif

У меня переключение разрешения экрана выглядит так:
https://pp.userapi.com/c834201/v834201338/39df/dNt69gN8Byo.jpg
Замечу что glClear чистит часть которую не должно быть видно - значит gpu ещё трудится обновлять изображение за границами окна Твою репу пока не собирал, но полагаю, что там будет то же самое и у тебя просто на убунте этот баг проявляется только с 640x480, а не со всеми режимами.

По скрину не очень понятно что не так. Это нативное разрешение дисплея, которое видно в настройках системы, и в которое можно установить десктоп без прокрутки, вот так выглядит? Если нет, это может быть виртуальное разрешение, которое вполне себе поддерживается системой. Если SDL 1.2 и 2 у вас ведет себя по разному, то могу предположить, что есть различие в том, как они скомпилированы. SDL поддерживает смену разрешения через XRANDR и XVIDMODE. Все в итоге сводится либо к X11_XRRSetCrtcConfig, либо к X11_XF86VidModeSwitchToMode. Больше я не вижу где может быть проблема.

Но зачем? Это довольно бесполезная фишка

Чтобы написать на ней плеер. Если во время работы либа разрешение менять не умеет, то для смены размера окна придётся перезапускать всё приложение, что приведёт к миганию окна.

SDL не изменяет виртуальное разрешение экрана. он изменяет именно режим видеоадаптера. При этом SDL говорит оконному менежджеру растянуть окно на весь экран. Видимо в каких-то модных оконных менеджерах окно растягивается правильно только на видимую часть экрана. Но у меня на всех десктопах включая оффтопики это не работает и в итоге получается то что видно на скрине. режим правильный. Просто окно находится не там где должно.
Ради эксперимента сломал в SDL функцию X11_SetWindowFullscreen чтобы он не выставлял флаг полного экрана оконному менеджеру - в результате получил корректную работу при условии что окно сразу создаётся полноэкранным.

Хмм. Попробовал еще Fedora, на nvidia, AMD и интеле. Никак не могу проявить ваш баг. Попробуйте все же мой код. Еще я использую код из hg clone http://hg.libsdl.org/SDL, не из репы системы, в этом еще может быть разница.

Я проверяю релиз 2.0.7 сейчас. С openbox теперь не проявляется. Значит они всё же что-то исправили. Надо будет на винде проверить. Но такая зависимость полноэкрана от wm - плохо. в wine например таких проблем нету.

C wm и так идет плотное общение в SDL_x11window.c, без всяких фулскринов. Это логично что wm должен быть вкурсе (если окно не помечено как игнорируемое wm), без этого никуда.

qt

кросплатформенность

Сложно. Так в чем проблема?

а 2.0 не катит! почему так я до сих пор не понимаю... может Вы знаете?

Скорее всего потому, что выход SDL2 запоздал. Поддержка платформ была ограниченна. Если мне не изменяет память, то для получения поддержки ios и android нужно было заплатить (возможно так было только для коммерческих игр).
Кроме того, API кардинально поменялся.

Я наверно перепутал его с freeglut или с чем-то еще таким.

Это тоже практически нужный уровень.

У меня даже на Intel HD Graphics 2500 дополнительный рендер через fbo отнимает треть fps.

Что за дополнительный рендер? В том же ios всегда рендерится в fbo, но проблем нет.
Проблема на старых девайсах - тяжелый шейдер и заоблачный фреймрейт. Но к вашей проблеме оно отношения не имеет.

Есть примеры десктопного софта(не игр) на ней?

Blender

Я бы даже сказал не только на ios, на андройде без вариантов SurfaceFlinger, на винде dwm.exe, на лине. Абсолютно все мажорные OS используют этот подход, т.к. накладные расходы на современном GPU <1% даже на мобилах, страдает только память. Линукс, кстати, единственная OS, где все еще без проблем можно откатиться на старый механизм.

Blender

Когда это Blender стал использовать SDL?

Blender использует собственный тулкит GHOST, он может как использовать SDL, так и не использовать. С натяжной можно считать за правду.

кросплатформенность

Это к плюсам sdl.

gnuradio-companion

Благодарю.

Самое кросплатформенное решение это вебморда. На первый взгляд в вашем случае применение SDL выглядит странно.

Помню только, что у qt тогда lgpl еще не было

Скорее всего тогда ещё было принято экономить процессор и память.

угу, современный браузер, иксы и дохлый баребон. Когда sdl аппликуха отлично крутится в directfb. Да и вообще, программировали как умели) Сейчас яб не раздумывая делал на андроиде.

Кстати, софт продается более 10 лет. А его предшественник был написан во времена win 3.11. К вопросу об ангулярах, реактах и прочего буллшита.

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

«Тогда» это до 2009 года? Дело совсем не в ресурсах, браузеры и в 98-м не тормозили, просто раньше это было не принято.

GLFW лучше, потому что не хренов комбайн

Поддержка ондроеда у SDL ужасна. Я понимаю, что у гугла примеры нативных приложений тоже криво написаны, но это же не повод делать хуже. С одной стороны, тут стоило бы кинуть чем-нибудь в вендоров (особенно в Леново), но можно же было и такие кейсы похендлить. Пришлось свою реализацию писать, потому что глупые пользователи не понимают, что если они выбрали платформу с зоопарком, не работать может именно у них

Поддержка ондроеда у SDL ужасна.

Расскажи свою историю, поделись опытом.

Нету особенной истории, нативные примеры от гугла тоже не умеют толком хендлить сворачивание, и SDL делает это не на всех девайсах. Чтобы не терялись ресурсы, SDL сохраняет их в отдельном контексте и потом копирует из него создавая шареный. Уже это надо делать аккуратно, а на некоторых китайских устройствах пропускать пару кадров потому что они не готовы,. Но тут такое дело, что если мы всё равно храним шареный контекст, то вместо этого почему просто не детачить текущий чтобы его система не прибивала? С таким подходом работает на чуть бОльшем количестве девайсов.

Использую и glfw, но надо еще выводить и аудио. Получается либо один SDL, либо glfw + что-то еще. Так же константы сканкодов клавиш у SDL соответствуют USB HID стандарту, а вот у glfw хоть и написано что им вдохновлялись - не соответствуют. А так штука хорошая, да.

Что то я не вижу этой логики в самой либе в SDL/src/video/android. Да и в андройдном примере там java которая грузит so`шки, а не нативное активити. Можете показать где это происходит?