In che modo l'output della GUI funziona dall'applicazione al livello hardware?

Question

Sto entrando nella programmazione della GUI e ho fatto qualche ricerca. Ora non tutto è chiaro per me. Se usassi GTK + come toolkit, come comunica con la scheda grafica?

Su un sistema Linux suppongo che sarebbe GTK -> X Server - (OpenGL) -> scheda grafica. È giusto?

Ho letto che alcune GUI disegnano direttamente OpenGL (ad esempio Blender3D), quindi come fanno le altre app a disegnare le loro GUI?

Se le uniche API (che io sappia) per le schede grafiche sono Direct3D e OpenGL, qual è la differenza tra il rendering del software e l'accelerazione hardware?

Il software che esegue "rendering software" può scrivere direttamente nel framebuffer della scheda grafica, in modo che OpenGL non sia stato toccato?

PS: scusate per le tante domande, ma io in realtà non capisco come che tutte le opere, grazie per ogni risposta :)

Answer 1

Su un sistema Linux suppongo che sarebbe GTK -> X Server - (OpenGL) -> scheda grafica. È giusto?

No. GTK + su Linux va

           /-[ if direct context ]---\ 
        /--> OpenGL >-+---------/       \ 
        /   \-> GLX -+--------------\    \ 
       /      \    \    \ 
GTK+ -+-> cairo >-+---> XRender >--------+----+-> Xlib/xcb >-+-> X server >-+-> Kernel Module >-> GPU 
     \   \–-> pixmap buffer >–/ 
     \       /
     \―---------------------------/ 

Ho letto che alcuni GUI disegnare direttamente OpenGL (per esempio Blender3D), così come si fa altre applicazioni disegnare le loro interfacce grafiche?

È solo "Blender" (senza 3D finale). Il toolkit GUI di Blender utilizza OpenGL come unico back-end, sì. Ma la GUI non è disegnata direttamente con OpenGL, che sarebbe semplicemente ingombrante con cui lavorare (disegna ogni singolo pulsante usando le chiamate OpenGL. Blender ha il suo proprio toolkit. GTK + è un altro toolkit ma non legato a Blender (infatti, uno dei miei pet project sta estraendo il toolkit GUI di Blender, in modo che possa essere utilizzato in progetti indipendenti)

I toolkit come GTK + e Qt sono progettati per la massima portabilità Blender ha il lusso di sapere che ci sarà OpenGL disponibile. Le app sviluppate per GTK + o Qt potrebbero essere eseguite su sistemi non 3D, quindi il design di GTK + e Qt consente di eseguire su un numero di backend.GoK + ora nella versione 3 utilizza il motore grafico Cairo come backend grafico. i propri backend, ovvero un rasterizzatore software che si disegna in pixmap (immagini pixel), o che trasmette i comandi di disegno a un'architettura grafica sottostante. f Cairo su Linux può essere OpenGL o X11 (core e estensioni del protocollo XRender).

Se le uniche API (che io sappia) per le schede grafiche sono Direct3D e OpenGL, qual è la differenza tra il rendering del software e l'accelerazione hardware?

Né OpenGL né Direct3D comunicano con la scheda grafica. Parlano con i driver della scheda grafica. Quindi l'opzione che avresti sarebbe, parlando con i driver da solo, bypassando OpenGL e Direct3D. Ma perché lo faresti? È noioso.

Su Windows, inoltre, sono disponibili GDI e/o WPF (Windows Presentation Foundation) per il disegno e Direct2D.

Su Linux si ottiene il core X11 e il protocollo di estensione XRender per disegnare belle immagini.

Un'altra API in crescita è OpenVG, che mira a standardizzare tutte quelle API di disegno 2D. E almeno in Linux OpenGL e OpenVG sono stati selezionati per diventare le uniche API di disegno astratto disponibili a lungo termine, con alcuni sistemi di finestre per la gestione del framebuffer e dell'input dell'utente. C'è Wayland in sviluppo (di cui non mi piace completamente il design) e X11, che ritengo abbia il design migliore (è un sistema orientato alla rete, che consente un'esecuzione distribuita, cosa che considero molto importante in futuro), ma ha bisogno di un completa revisione in alcuni "X12" - ripulire il cruft legacy, farlo funzionare in uno spazio colore di contatto, rendere le connessioni passibili (in modo da poter migrare i client tra X server, che consentirebbe un modo molto più elegante di bloccare sessioni X , spostando tutte le connessioni in qualche server X ombra, invece di cercare di bloccare l'accesso usando uno screen saver di blocco).

Il software che esegue "rendering software" può scrivere direttamente nel framebuffer della scheda grafica, in modo che OpenGL non sia intatto?

Non su un sistema operativo moderno. Tuttavia il sistema operativo può fornire un accesso astratto alla scheda grafica attraverso alcune API framebuffer (/ dev/fb0 su Linux). Tuttavia, il framebuffer non è gestito, quindi se c'è un server X o Wayland in esecuzione, uno di questi è in fase di gestione dell'FB, e quindi non sono affari tuoi.

Answer 2

Il software che esegue "rendering software" può scrivere direttamente nel framebuffer della scheda grafica, in modo che OpenGL non sia stato toccato?

Non abbastanza o più accuratamente, dipende dal conducente. Non è che i sistemi di visualizzazione come XServer o gli equivalenti di Windows e OSX effettivamente usano le API ma piuttosto descrivono e API (più precisamente un modello di driver o in caso XServers uno di più modelli come XAA, EXA, UXA e DRI) che il driver del display deve soddisfare.

Tutto ciò che non è definito in questi modelli deve essere fatto in "software" e calcolato sulla CPU, inoltre alcune delle operazioni definite dai modelli possono essere calcolate anche dalla CPU dal driver.

OpenGL utilizzato per essere completamente separato standard da questi modelli e driver grafici non ha dovuto implementare OpenGL affatto per essere utilizzato dal sistema operativo. Ma con la continua integrazione della grafica 3D e il compositing più complesso nei moderni sistemi operativi, i modelli di driver hanno iniziato a fare affidamento sugli stessi paradigmi di OpenGL e DirectX. Ad esempio, WDDM ouright richiede il supporto per DirectX9.