Autoři SDL se snaží vyřešit problém fullscreen her

S fullscreen hrami na Linuxu je to aktuálně složité, protože je okolo způsobu implementace spousta nejasností. Ryan C. Gordon (icculus) a Sam Lantinga připravili návrh, jak by mohla probíhat indikace fullscreenu pro správce oken a jak by se řešilo přepínání rozlišení. Jde jim o podporu tohoto v SDL. Mezitím se ozval Martin Gräßlin z KDE, kterému se to až tak moc nelíbí, ale i tak vyjádřil návrhu podporu.

25.10.2012 14:26 | Luboš Doležel (Doli) | Zajímavý software

Komentáře

[Dreit]

Nejvíc mě štve, že u některých her mám ve fullscreenu přecitlivělou myš, posun o jeden pixel ve Fluxboxu odpovídá tak 400px ve hře....a s tím se na Arrakis fakt nedá hrát

[skywaker]

to ja stále fičím na allegre :D

[D.A.Tiger]

Pěkné +1

Jaká je nová verze? Já se ještě nedostal k tomu ho vyzkoušet....

[Jardík]

Bohužel mizerný stav. Aplikace vůbec nemá co rozlišení měnit, obzvláště ve vícemonitorové konfiguraci. aplikace to buď vždy rozesere a vrátí do špatného stavu, nebo to do předchozího stavu nevrátí vůbec, protože spadne (což je poměrně častý jev u špatně portovaných her typu Torchlight). Aplikace si má jen požádat o fullscreen, WM se pak má rozhodnout, jestli ano/ne a má se přizpůsobit rozlišení, jaké ji věnuje WM. Uživatel si pak může WM nastavit, jak se k dané hře chovat (např. i změnou rozlišení výstupu a nastavení viewportu X screenu tak, aby to nic nerozesralo). Hotovo. Linux není Windows a nic jako exclusive fullscreen mode není, vývojáři by si to mohli uvědomit.

[chrono]

Otázne je, či sa o to má starať práve WM. (podľa mňa to nie nie je záležitosť, ktorý by mal riešiť WM; WM by mal maximálne dostať informáciu, že bolo rozlíšenie zmenené na žiadosť nejakej aplikácie)

[Jardík]

No spíše než WM by to mělo být na uživateli, co by si třeba dané WM nastavil že když se dané okno zobrazí, tak se zavolá to a to a přepne se rozlišení a po zmizení zase zpět. Já jsem ten návrh sice nečetl, ani argumenty proti, ale osobně jsem proti, hra by v žádném případě neměla měnit rozložení mé obrazovky, ani přes nějaký WM hint. O fullscreen si říct může (takový WM hint už existuje), ale aby mi jebala z rozlišením, to rád nemám. Osobně mám k notebooku připojen externí displej a nesnáším, že hry zapínají/vypínají můj displej jak se jim náhodně líbí, že mi rozhazují ikony na ploše a že si po sobě ten bordel pak neuklízí. Kdyby alespoň provedli něco tak primitivního, jako mít jakýsi spouštěč, který rozlišení nastaví a po ukončení hlavní binárky (ať už normálně či pádem) vše vrátí zpět (a tím, že spouštěč implementuje jen toto, tak nehrozí nějaké ponechání bordelu pádem). Jenže ono je moderní změnit rozlišení v aplikaci, která je složitá, ráda padá a pak nic nevracet zpět. A nedej bože, že uživatel během spuštěné hry zapojí jiný výstup, popř. existující odpojí. To se hra zblázní i po správném ukončení a klidně vám zanechá "mrtvý" desktop, kde nic nevidíte a po slepu spouštíte xrandr.

[D.A.Tiger]

To se hra zblázní i po správném ukončení a klidně vám zanechá "mrtvý" desktop, kde nic nevidíte a po slepu spouštíte xrandr.

Tohle mi s chutí dělaj winehry když přijde přes notifikátor nějaká událost. Zajímavé je, že to nedělají e všechny hry co jedou v celoobrazovkovém režimu. u těch o kterých to vím musím ve spouštěči potom kontrolovat stav Pidginu, jestli náhodou nejede Thunderbird, atpd... tohle je občas na pos***í. A to nemluvím o KDE, tam je nejlepší dočasně vypnout kompositor....

[Trip]

Nechci vám do toho mluvit ale sám se už dlouhou dobu snažím o vývoj nějaké té hry a to jak pro windows tak i pro Linux a z vlastní nedávné zkušenosti s enginem Love2D který využívá SDL tak mohu potvrdit že i když se snažím si před samotnou změnou rozlišení a fullscreenu uložit stávající stav systému a při pádu či standartním ukončení vše navrátit nazpět tak se tak nestane. Důvod je jednoduchý implementace v SDL nefunguje správně. Tedy funguje ale v případě "správné grafiky/ovladačů a konstalace hvězd". A myslím že to není normální aby nějaký projekt(hra) byla tak špatně napsaná a neřešila vrácení stavu rozlišení do stavu jako před spuštěním. To je stejná konina jako že projekt napsaný v c++ nebude uvolňovat paměť kterou si před tím alokoval jen pro to že se o to postará systém.

[Jardík]

Důvod je jednoduchý implementace v SDL nefunguje správně. Tedy funguje ale v případě "správné grafiky/ovladačů a konstalace hvězd".

Samozřejmě, v SDL je to špatně, jenže za špatně považuji i to, že se o to hra pomocí SDL pokouší. Změnu rozlišení by si měl zajistit nějak uživatel, ať už nastavením WM, který něco spustí, aby se rozlišení změnilo, nebo nějak jinak. Ale nepřijde mi správné, že mi hra najednou kompletně změní celý layout obrazovky, aniž bych ji o to požádal, či ji tak nastavil. A když už ji o to požádám, musela by si zapamatovat nejen stav před aktivací fullscreenu (tak jak to dělá SDL), ale i další stavy, jak si uživatel sám mění layout obrazovky během hraní hry (např. se rozhodne během hraní aktivovat druhý displej a tam si bude chatovat, číst návod, apod.). To ale přidává do aplikace spoustu kódu, často i zbytečného, protože jen málokterý uživatel se takto chová, ale měl by tam být i pro toho jednoho, jinak to nikdy správně nebude obnovovat správný stav obrazovky. Je mnohem jednodušší nastavit si WM a říct mu "když uvidíš okno to a to, spusť xrandr blabla a až okno zmizí, spusť xrandr blabla". Uživatel tak má kontrolu nad rozlišením pro danou hru a hra se prostě přizpůsobí danému rozlišení, rozhodně by neměla být naprogramována s předpokladem např. "moje okno je vždy 1024x768px".

To je stejná konina jako že projekt napsaný v c++ nebude uvolňovat paměť kterou si před tím alokoval jen pro to že se o to postará systém.

Však tohle vám neberu a s tímto souhlasím. Pokud ale člověk nedělá kokotiny typu "dynamická alokace kvůli každý blbosti" a naučí se správně používat různé kontejnery apod. tak ho to vůbec trápit nemusí. A pokud už se k dynamické alokaci musíme uchýlit, je tu třeba std::shared_ptr s téměř nulovým propadem výkonu (kompilátor vše zoptimalizuje) a o kraviny se nemusíme starat. Stačí se správně naučit programovat, neprogramovat stylem "vlastní kontejner pro každou blbost, protože add() se mi píše lépe než push_back()" a nepoužívat debilotiny typu Qt kontejnery, který se zeserou při první vyhozené výjimce apod.

[----]

"A pokud už se k dynamické alokaci musíme uchýlit, je tu třeba std::shared_ptr s téměř nulovým propadem výkonu (kompilátor vše zoptimalizuje) a o kraviny se nemusíme starat."

Kompilátor zoptimalizuje tak velký h*vno, shared_ptr je triviální refcounted container, který se dá napsat na 30 řádcích, neprovádí se žádné optimalizace (a z principu, jak shared_ptr funguje, to ani nejde - tak, jak to dělají refcounted GC). Overhead shared_ptr není v žádném případě minimální, v podstatě ke každému pointeru přidá refcount (size_t) a při každém předání / uvolnění scope se na něm provede in/dekrementace. Shared_ptr je prostě "konzistentně pomalý", funguje pro soft-realtime (nicméně dnešní GC jsou skoro všechny minimálně inkrementální a původní two-color mark-sweep se skoro nepoužívá, takže GC je lepší volba), ale není to žádná sláva. Kromě toho nezvládá cyklické reference a nejde moc dobře skloubit s multithreaded prostředími.

[little.owl]

Overhead shared_ptr není v žádném případě minimální, v podstatě ke každému pointeru přidá refcount (size_t) a při každém předání / uvolnění scope se na něm provede in/dekrementace.

Presne tak, nehlede k tomu ze reference counting musi byt thread safe a to neni levne ani pri pouziti atomickych operaci.

[Jardík]

No já tím nemyslel, že zoptimalizuje reference counting, ale že zoptimalizuje přístup k tomu pointeru, co tam je, tj. že nebude volat ptr() jak debil. Poté, co mám někde daný ukazatel takto někde obalený (nebo třeba v unique_ptr) si pak klidně můžu s obyč pointerem dělat co chci a zároveň se nestarat o nějaké jeho uvolnění.

[stativ]

Až nas to, že NETWM API je už takhle navržené. Bohužel spousta aplikací používá svoje vlastní pofidérní řešení fullscreenu, které je ještě mnohem horší, a pak to vypadá, tak jak to vypadá (a největší sranda je, jak psal Jardík, s více monitory).

[D.A.Tiger]

Já myslím, že by to měl dělat WM ve spolupráci s X-kama. Třeba takto : WM si nejprve zjistí zda je požadované rozlišení k dispozici, pak nastaví danému oknu příznak typu "vždy v popředí", zbaví okno rámu a dekorací, to co zbude posune na pozici [0,0]. Potom požádá X-ka o změnu rozlišení.

[Jardík]

Jenže když máte 2 monitory, není to sranda. Máte řekněme monitory takto:

|=======X screen========|
||-----------|---------||
||  Output   | Output  ||
||    1      |    2    ||
||-----------|         ||
|            |---------||
|=======================|

a spustíte na monitoru 2. Přesunout na pozici 0,0 je v tomto případě blbost, protože to je monitor 1. Pokud spustíte na monitoru 1, nelze zase změnit velikost X screenu (což je w1+w2 x h2), ale je potřeba změnit rozlišení výstupu 1 tak, aby se nepohnulo z výstupem 2 a nadále mi fungovali aplikace na druhém monitoru. Sice asi není časté, že hrajete hru a zároveň něco děláte na druhém monitoru, ale třeba číst k nějaké složitější hře nějaký návod se občas hodí. Nějaký exclusive fullscreen by s tím vyjebal.

|=======================|
||-------|   |---------||
||   1   |   |         ||
||-------|   |    2    ||
|            |         ||
|            |---------||
|=======================|

Někdy by zase uživatel rád hru přes oba monitory a tady nemusí pomoci ani fullscreen hint, protože WM většinou udělá fullscreen v rámci výstupu, na kterém je okno.

Nejlepší je tedy v rámci aplikace vůbec rozlišení neřešit a nechat to na uživateli, ať si to nastaví jak chce, kde chce, třeba nějak i v rámci nastavení WM pro danou aplikaci. Aplikace/hra by se měla umět přizpůsobit jakémukoliv rozlišení, co jí hodíte.

[j]

Vicemonitorova konfigurace + hry to je tragedie i na widlich, takze nevidim zasadni rozdil ... ;D. Kdykoli si clovek neco pusti, tak ho ceka prekvapko.

[Jardík]

Já vím, taky s tím mám zkušenost. I na windows je fullscreen s více monitory nechutná věc. Proto si myslím, že by se prostě o to aplikace neměla snažit a uživatel sám by si měl sám nastavit, jaké rozlišení a jakým způsobem ho docílit, ať už přes WM, nebo jinak. Aplikace nemá křišťálovou kouli, aby to prostě nepodělala, jen uživatel ví, jak to chce. Nebo taky další zkušenost s linuxovým portem Torchlight - jednou spustím ve fullscreenu na 1280x1024, další den to spustím na displeji notebooku, který umí max 1280x800 a hra prostě padá a padá, dokud si ručně neupravíte konfigurák hry, prakticky nulový fallback. Kdyby na to hra kašlala a nechala to na uživateli, mohla hra klidně správně běžet ve fullscreenu, protože by ji WM prostě udělal tak velké okno.

[luky]

Vicemonitorova konfigurace + hry to je tragedie i na widlich

Vicemonitorova konfigurace je tragedie hlavne na Widlich. Taskbar je jen na jednom monitoru a obsahuje okna ze vsech monitoru - vrchol demence - chcete prepnout okno a musite ujet klidne nekolik tisicu pixelu mysi. Nedej boze, kdyz ty monitory maji ruzne rozliseni.

[Jardík]

Ve Win 8 jde taskbar nastavit na všechny monitory a taky lze nastavit, jestli na každém budou všechna okna či jen okna z daného monitoru. Nebo alespoň to tak bylo v nějaký tý preview verzi, co jsem zkoušel. Pozdě, ale přece. Win 8 je ale taková splácanina a k srdci mi nepřirostl.

[D.A.Tiger]

Jenže když máte 2 monitory, není to sranda...

Chápu správně, že máte na mysli jednu plochu na dvou monitorech s různým rozlišením?

[Jardík]

Ano. Je to právě můj případ. Mám notebook s 1280x800 a vedle něj monitor s 1280x1024.

[stativ]

Trochu jsem nad tím přemýšlel, a řekl bych, že mě napdlo docela elegantní a funkční řešení, které ale bohužel zatím asi nehrozí – řešit tohle na úrovni waylandu/X (spíš bych to viděl na ten wayland). Fullscreen (i se změnou rozlišení) by se řešil tak, že by se obrazovka, na které má být hra puštěna dočasně „vypnula“ a místo ní by se vytvořil nový grafický výstup, který by měl příslušné parametry, který by měl jako potomka danou aplikaci.

Ve výsledku by to tedy fungovalo stejně, jako když člověk vytvoří nový xserver, ve kterém spustí aplikaci (třeba hru). Když se hra ukončí (ať už korektně nebo spadne), server se vypne taky.

Tím, že by se to integrovalo přímo do X/waylandu, šlo by vyřešit i problémy které u ručního řešení se separátním x serverem nastávají ve chvíli, když už několik xserverů beží. Navíc tím, že by to bylo přímo integrované v serveru by se mohla obejít spousta věcí okolo inicializace a tudíž by to mohlo být výrazně rychlejší než je v současnosti separátní x server. Další výhodou je to, že by na pozadí neběžel kompozitní správce oken, který by mohl snižovat výkon.

[stativ]

+1

[Dreit]

Plně se ztotožňuji s tímto názorem!

[AsciiWolf]

+1

[David Jaša]

Aplikace si má jen požádat o fullscreen, WM se pak má rozhodnout, jestli ano/ne

Do toho jestli ano/ne nemá VM co kecat.

Osobně je mi nejsympatičtější tenhle přístup, nejlíp ještě doplněný o nějakou X-wide zkratku, která dotyčnému oknu vezme veškerý fokus a vrátí obrazovku zpět do původního stavu.

[Jardík]

Do toho jestli ano/ne nemá VM co kecat.

Do toho WM samozřejmě co kecat má, obzvláště, když to uživatel tomu WM nejǎk "přikáže". WM může ignorovat i obyčejný _NET_WM_STATE_FULLSCREEN hint. Např. takový compiz aplikaci nedovolí jít do fullscreenu, dokud si nanastaví, že je možné měnit velikost okna (takový problém má např. torchlight, vytvoří okno s fixní velikostí bez možnosti její změny, pak se snaží přepnout do fullscreenu, ale compiz to nedovolí a lidi si pak stěžují na fóru, že jim v ubuntu nefunguje torchlight ve fullscreenu.

[Jardík]

Jinak ještě k tomu "pak se snaží přepnout do fullscreenu", což má samozřejmě za následek změnu velikosti okna a tu si aplikace sama zakázala a WM ji to dovolil a pak se aplikace diví, že jí to nejde. Vina jak na straně aplikace, tak i nastavení WM, resp. volby WM s tímto chováním.

[Jardík]

Teď jsem se kouknul na ten link a jedná se o něco podobného jako zmiňuji v komentáři výše, nezmění se x screen, ale pouze daný výstup.

[petr_p]

A přesně toto je problém SDL. Drtivá většina jejích aplikací začíná voláním udělej mi okno takhle velké a aplikace je pak celá postavená na rastrovém modelu, kdy není schopná přežít změnu velikosti.

V posledních dvou verzích SDL vývojáři nejprve nahradili xf86vidmode za xrand a pak jej zase vypnuli, protože ať zvolili jakoukouliv metodu, vždy se našel uživatel, kterému automagie dávala špatné výsledky.

Chápu autory, že to mají těžké, ale osobně si myslím, že by měli přestat řešit protichůdné požadavky a prostě by měli dovolit přeškálovat výstup místo měnění videorežimu.

[Limoto]

+1

[Petr Ježek]

E? Ono to při načtení fullscreen hry neumí nastavit grafické rozlišení z menu? Že bych něco jako velmi příležitostný pařan vyignoroval? A že se mládencům od KDE něco nelíbí - mně se toho nelíbí :)

[Luboš Doležel (Doli)]

Zkus pak z té hry udělat Alt+Tab.

[petr_p]

To ale v X11 neuděláš, protože v okamžiku, kdy aplikace požádá SDL o fullscreen, tak SDL automaticky zamkne focus.

[Rovano]

Tak ve Wine chyba nebude, nebo ji některé hry umí pomocí hacků obejít.

Takový Starcraft 2 ve Wine a ALT+TAB fungovalo precizně včetně mute-unmute zvuků. Testováno s Compizem na Ubuntu. Což je jinak velmi nepřátelské prostředí pro fullscreen z nějakých důvodů. Mám odpozorováno, že Kwin je v tomto přátelštější. Ale jak známo, co pes, jiná ves.

[Jardík]

Fullscreen v compizu je k fullscreenu přátelský, jenom nedovolí fullscreen aplikaci, která si předtím usmyslela, že její okno má mít pevnou velikost, která se nemá dát změnit. Jelikož přepnutí do fullscreenu způsobí změnu velikosti, je naprosto v pořádku, že compiz pak takový požadavek na fullscreen ignoruje. A díky jeblé specifikaci je i v pořádku případ, kdy to WM dovolí (kwin).

[Jardík]

Fullscreen v compizu je k fullscreenu

Uhh ... ^^

[Rovano]

No co.