Qual è il contenuto del buffer * dopo * una chiamata a glSwapBuffers ()?


8

( SDL_GL_SwapBuffers()in particolare)

Quando hai disegnato una scena e chiami buffer di scambio, è normale che glClear()la scena sia prima di disegnare qualsiasi cosa; se non si cancella, qual è il contenuto del buffer? È definito da qualche specifica o varia in base al driver?


Questa è una domanda molto interessante.
Notabene,

Risposte:


13

I dettagli su come scambiare il buffer anteriore e posteriore variano da piattaforma a piattaforma, quindi la risposta dipende dalla piattaforma.

Secondo la documentazione di riferimento GLX glXSwapBuffers :

Il contenuto del back buffer diventa indefinito dopo uno scambio. Si noti che questo vale per i buffer di pixel e per Windows.

Tuttavia, esiste l' estensione GLX_EXT_buffer_age :

Lo scopo di questa estensione è quello di esporre informazioni sufficienti alle applicazioni su come il driver gestisce il set di buffer anteriori e posteriori associati a una determinata superficie per consentire alle applicazioni di riutilizzare il contenuto dei vecchi frame e minimizzare quanto deve essere ridisegnato per il fotogramma successivo.

Ma Win32 SwapBuffers dice solo:

Se il formato di pixel corrente per la finestra a cui fa riferimento questo contesto del dispositivo include un buffer posteriore, la funzione scambia i buffer anteriore e posteriore ... Se il formato di pixel corrente per la finestra a cui fa riferimento il contesto del dispositivo non include un buffer posteriore, questo call non ha alcun effetto e il contenuto del back buffer non è definito quando viene restituita la funzione.

E CGLFlushDrawable, per OS X Core Graphics dice:

Se l'attributo dell'archivio di backup è impostato su false, i buffer possono essere scambiati anziché copiati. Questo è spesso il caso in modalità a schermo intero. Se il destinatario non è un contesto con doppio buffer, questa chiamata non fa nulla.

Infine, nella funzione di scambio di buffer standard OpenGL ES eglSwapBuffers :

Il buffer di colore della superficie non viene definito dopo aver chiamato eglSwapBuffers.

Cosa significa tutto ciò?

  • Per essere veramente multipiattaforma, non puoi assumere nulla sul back buffer dopo uno scambio. Il suo contenuto è indefinito e probabilmente dovresti glClear o ripararlo prima di usarlo.
  • Se si utilizza Linux, è possibile verificare l'estensione dell'età del buffer. Poiché un sistema potrebbe essere a triplo buffer, potrebbe essere necessario tenere traccia di più frame di danni e occuparsene.
  • Se stai usando OS X, potresti essere copiato e potresti ottenere uno scambio. Quindi puoi presumere che il contenuto del backbuffer non sia spazzatura, ma non controlli se si tratta del frame che hai appena inviato o di quello precedente.
  • Se stai prendendo di mira solo Win32 e sei sicuro di avere un back buffer, puoi presumere presumibilmente che il suo contenuto sia quello che era nel buffer frontale. (Anche se questo è un presupposto per omissione piuttosto che esplicitamente dichiarato; non sarei sorpreso se non funziona su molte / qualsiasi configurazione.)

Dati i vincoli di GLX e CGL e il desiderio di minimizzare i cambiamenti tra OpenGL e OpenGL ES, si potrebbe anche supporre che il contenuto sia spazzatura.


1

Da quello che ho letto l'unico comportamento è UNDEFINED. Quindi suppongo che non vi sia alcuna garanzia su quale sarà il contenuto del buffer. Per non parlare del fatto che alcune librerie eseguono effettivamente una chiamata chiara nella chiamata dei buffer di scambio.


-1 per mancanza di approvvigionamento; La documentazione di OpenGL è abbondante e facilmente collegabile.

+1 perché, beh, ha effettivamente risposto e la risposta era corretta. Le fonti sicuramente aiutano, ma non sono assolutamente necessarie!
o0 '.

@ Lo'oris: Tranne, beh, non ha ragione. È corretto per alcune piattaforme, ma non tutte, come spiega la mia risposta.

@Joe: l'unica risposta corretta indipendentemente dall'ambiente è questa, come spiega la tua risposta. Codificare sapendo che questo si romperà "da qualche parte" sarebbe sbagliato in primo luogo.
o0 '.

1
@ Lo'oris: è probabile che tutto il codice, specialmente il codice di rendering, si interrompa da qualche parte . Una buona risposta non solo lo dice, ma spiega dove si trova da qualche parte.

0

Il comportamento è UNDEFINED, quindi se hai intenzione di riempire comunque l'intero schermo, potresti considerare di abbandonare il chiaro ... tranne, in alcuni ambienti (almeno alcune architetture di piastrellatura), che degraderanno effettivamente le prestazioni. Lo schermo intero all'inizio del rendering è un'operazione così comune che sarei sorpreso se non fosse ottimizzato bene su tutte le piattaforme di destinazione.

Il motivo per cui è UNDEFINED è che per molte architetture, definire lo stato del contenuto sarebbe un sovraccarico aggiuntivo, indipendentemente da come definire lo standard.

Quanto a quello che troverai lì, posso fare un'ipotesi basata sull'esperienza;

Su architetture a doppio (o multi) buffer, come la maggior parte dell'hardware video per PC desktop, è probabile che tu trovi gli "altri" dati del buffer. Ciò non è garantito, poiché non è nelle specifiche, se qualche strana ottimizzazione ne trae beneficio, danneggeranno i dati.

Sulle architetture piastrellate, è possibile trovare gli stessi dati dell'ultimo fotogramma, alcuni dati stranamente confusi in base alla dimensione della piastrella o qualsiasi altra cosa.

Quindi hai alcune architetture strane (come l'NDS) che potrebbero darti praticamente qualsiasi cosa, poiché la loro definizione del buffer non è esattamente quello che ti aspetteresti.


Caspita, voti negativi. Sono serio su ciò di cui ho scritto, soprattutto se stai scrivendo per l'hardware mobile, assicurati di includerlo chiaramente.
Jari Komppa,

Ho annullato il voto perché la tua risposta è quasi identica a quella di David, non ha ancora riferimenti e, come quella di David, non è corretta né l'intera storia.

Ok. L'unico riferimento che posso dare, tuttavia, è la mia esperienza. Starò più attento.
Jari Komppa,

Ho annullato il voto perché questa risposta è stata la peggiore delle altre due (che ho entrambe votato): non ha aggiunto nulla ed era molto meno chiara.
o0 '.
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.