Vlákno názorů k článku Vulkan: vytvoření okna od mad - Laickym pohledem co do slozitosti a delky kodu...
-
Tak to máte neco spatne.
Na tabletu Surface Pro je to jediny kompozitor, se kterym se da pracovat a spravne skaluje na 4k. Xorg ma spatne tlacitka, velikosti. A tablet strasne hreje. Prominte, ze pisu bez diakritiky, ale pisu na virtualni klavesnici v ubuntu.
NVidii mam rtx pres dkms driver 515 a az na par drobnych veci jako focus okna v jave je to taky bez problemu. KDE pada hned po startu s nejakou vyjimkou, ale to je mozna moje chyba dlouho jsem to nezkousel.
Dokonce i hry ve wine jedou uplne bez problemu, spis se mi zda, ze u starych her je to lepsi, ale to je spis diky XWaylandu. Nejnovejsi hry poustim na xorg, protoze takove wine proste je, ale i na waylandu a nvidii rtx jedou pod waylandem bez problemu. Diky za wayland, jinak bych asi ted nemohl surfovat a psat na surface. -
Nebudu si hrát, že jsem Wayland guru - to ať případně udělají ti, kteří s Wayland i dýchají. Nicméně ze své zkušenosti bych řekl, že Wayland je super v tom, že si věci jakoby postavíte jak krabičky, a propojíte drátkama a ono pak celá hotová krabice jede. Na rozdíl od toho Win32 a Xlib máte, zjednodušeně řečeno, jedinou funkci CreateWindow, která si bere hromady flagů, ale mimo to nemáte nad věcmi další kontrolu. Je to mnohem více black box. Věci jako HiDPI support je pak realizováno množením funkcí kolem a dalšími zprávami, které okno dostává. Tímto způsobem se prodlužuje život něčeho, co už dle dnešních standardů není moderně navrženo, podle mě.
Na rozdíl od toho je Wayland mnohem více flexibilní a máme větší kontrolu nade vším. Proto i více řádků kódu, protože nemáme black box, ale krabičky a drátečky k propojení.
Nevím jestli by u reálné aplikace, kde nepoužíváme jen základní funkce a nevytváříme jen jedno jednoduché okno - nevím, jestli by Win32 či Xlib měly stále výhodu méně kódu. Spíše bych se asi klonil k tomu, že ne (?).
-
Samozřejmě nic proti vašemu názoru a preferenci. WinAPI má svoje kouzla a je udržováno již tolik let a nezastarává zatím tak, jak Xlib.
Dovolil bych si však sdílet svou zkušenost. WinAPI bylo rozhraní, které mi připravilo nejvíce překvapení a které mi připadá nejvíce ohekované. Pár příkladů:
(1) Funkce PeekMessage() nemá blokovat (na rozdíl od GetMessage()) a má se vrátit ihned, pokud ve frontě nečeká žádná zpráva. Nicméně pokud okno taháte po obrazovce, tak se tato funkce nevrací. Proč? Dokonce ani v dokumentaci se o tom nedočtete. Tedy nejen překvapení, ale i záhada.
(2) Vytvořili jsme okno a požádali o rozměry 1024x768. Ale co to? Vulkan rendruje do okna s rozměry 1004x725. Abychom dostali na Win32, co bychom si představovali, potřebovali bychom vytvářet okno větší o jeho dekoraci. API pro získání rozměrů dekorace existuje. Nicméně takovéto zábavě s WinAPI se asi v tomto tutoriálu věnovat nebudeme.
(3) Do třetice: Opravdu má okno i s dekoracemi rozměry 1024x768? Pokud nemáte historickou obrazovku, tak pravděpodobně ne. Windows DPI virtualization nám zvětšilo okno na našich FullHD a 4K obrazovkách, aby nevypadalo moc malé. Opravdové FullHD či 4K okno se nám tak na obrazovku vůbec nevleze. A nejen že nevleze. Požádáte o okno 3840x2160 a dostanete 1536x841. A to ještě nemluvím o souřadnicích myši - nechám otevřenou otázku, zda přijdou ve virtualizovaných souřadnicích nebo v opravdových souřadnicích systému. Hromada bolestí. Rozumím důvodům, proč se tak děje, i proč to vývojáři Microsoftu tak udělali, nicméně ve chvíli, kdy vám API dělá jiné věci, než o které ho žádáte, nevím, ale WinAPI mi připravilo nejvíce překvapení.
-
Sám sebe opravuji v bodu 1: Nejedná se o PeekMessage(), ale o DispatchMessage(), která se nevrátí, dokud okno taháme po obrazovce. Dokážeme si asi představit, jakou hrozbou je takovýto design pro síťové aplikace či hry, které potřebují každých pár desítek milisekund obsloužit všechny zprávy, které dostaly po síti.
