| Entrambe le parti precedenti la revisione
Revisione precedente
Prossima revisione
|
Revisione precedente
|
qt_windows_e_opengl_dinamico [2015/05/12 19:45]
mickele |
qt_windows_e_opengl_dinamico [2015/06/12 11:10] (versione attuale)
mickele |
| ===== Caricamento dinamico delle librerie OpenGL ===== | ===== Caricamento dinamico delle librerie OpenGL ===== |
| |
| Abbismo [[:qt_windows_e_i_driver_opengl_intel|già parlato]] della possibilità offerta dalle Qt in ambiente Windows, fin dalla versione 5.4, di adattarsi durante l'esecuzione al livello di implementazione delle OpenGL presente nel sistema di esecuzione. | Abbiamo [[:qt_windows_e_i_driver_opengl_intel|già parlato]] della possibilità offerta dalle Qt in ambiente Windows, fin dalla versione 5.4, di adattarsi durante l'esecuzione al livello di implementazione delle OpenGL presente nel sistema di esecuzione. |
| |
| Quanti di voi hanno avuto a che fare con la distribuzione di programmi con codice OpenGL in ambiente Windows sanno quanti mal di testa può determinare la a volte incompleta, a volte completamente assente, implementazione delle specifiche OpenGL presente in questo ambiente. Il caricamento dinamico delle librerie opengl sembrerebbe la panacea a tutti i problemi, dando la possibilità in fase di esecuzione di adattarsi al livello di implementazione delle specifiche OpenGL presente nel sistema. Per approfondire l'argomento, oltre al precedente [[:qt_windows_e_i_driver_opengl_intel|post]], vi rimando ad [[https://blog.qt.io/blog/2014/11/27/qt-weekly-21-dynamic-opengl-implementation-loading-in-qt-5-4/|un articolo sul blog ufficiale delle Qt]]. | Quanti di voi hanno avuto a che fare con la distribuzione di programmi con codice OpenGL in ambiente Windows sanno quanti mal di testa può determinare la a volte incompleta, a volte completamente assente, implementazione delle specifiche OpenGL presente in questo ambiente. Il caricamento dinamico delle librerie opengl sembrerebbe la panacea a tutti i problemi, dando la possibilità in fase di esecuzione di adattarsi al livello di implementazione delle specifiche OpenGL presente nel sistema. Per approfondire l'argomento, oltre al precedente [[:qt_windows_e_i_driver_opengl_intel|post]], vi rimando ad [[https://blog.qt.io/blog/2014/11/27/qt-weekly-21-dynamic-opengl-implementation-loading-in-qt-5-4/|un articolo sul blog ufficiale delle Qt]]. |
| In realtà non è tutto oro quello che luccica... | In realtà non è tutto oro quello che luccica... |
| |
| ===== Chiamata funzioni OpenGL dal programma ===== | ===== Chiamata funzioni OpenGL da programma ===== |
| |
| Il principio su cui si fonda quanto appena descritto è che il linking dell'eseguibile creato debba avvenire in fase di esecuzione. E qui incontriamo un grosso problema: non conoscendo al momento della compilazione il livello di implementazione delle OpenGL, non possiamo dire al compilatore con quali librerie linkare l'eseguibile. Questo vuol dire che nella fase finale di creazione dell'eseguibile il compilatore ci darà un messaggio di errore del tipo | Il principio su cui si fonda quanto appena descritto è che il linking dell'eseguibile creato debba avvenire in fase di esecuzione. E qui incontriamo un grosso problema: non conoscendo al momento della compilazione il livello di implementazione delle OpenGL, non possiamo dire al compilatore con quali librerie linkare l'eseguibile. Questo vuol dire che nella fase finale di creazione dell'eseguibile il compilatore ci darà un messaggio di errore del tipo |
| .../gltext2d.cpp:120: undefined reference to `_imp__glEnable@4' | .../gltext2d.cpp:120: undefined reference to `_imp__glEnable@4' |
| |
| Il problema viene risolto chiamando le funzioni OpenGL tramite la classe [[http://doc.qt.io/qt-5/qopenglfunctions.html|QOpenGLFunctions]]. Quando usiamo la classe QOpenGLFunctions ricordiamoci che l'istanza della classe deve essere inizializzata con il metodo initializeOpenGLFunctions(). | Il problema viene risolto chiamando le funzioni OpenGL tramite la classe [[http://doc.qt.io/qt-5/qopenglfunctions.html|QOpenGLFunctions]] usando |
| | |
| | QOpenGLFunctions *f = QOpenGLContext::currentContext()->functions(); |
| | f->glClearColor(1.0f, 1.0f, 1.0f, 1.0f); |
| | ... |
| | |
| | Se in alternativa creiamo un'istanza della classe QOpenGLFunctions, ricordiamoci di inizializzarla con il metodo initializeOpenGLFunctions(). |
| |
| ===== E QOpenGLTexture ? ===== | ===== E QOpenGLTexture ? ===== |
| |
| Il metodo appena descritto ad oggi non copre però una casistica: l'impiego della classe QOpenGLTexture! Poiché all'interno di tale classe vengono invocati comandi OpenGL senza l'accortezza sopra descritta, ecco riapparire i problemi di linkaggio visti sopra. Come risolverli? | Il metodo appena descritto non copre però una casistica: l'impiego della classe QOpenGLTexture! Poiché all'interno di tale classe vengono invocati comandi OpenGL senza l'accortezza sopra descritta, ecco riapparire i problemi di linkaggio visti sopra. Come risolverli? |
| |
| Una prima soluzione è quelle di creare una classe intermedia che eredita sia da QOpenGLTexture che da QOpenGLFunctions. In caso di scene complesse la soluzione appena descritta può non essere il massimo in termini di performance, vista la necessità di inizializzare ogni texture con initializeOpenGLFunctions(). | Una prima soluzione è quelle di creare una classe intermedia che eredita sia da QOpenGLTexture che da QOpenGLFunctions. In caso di scene complesse la soluzione appena descritta può non essere il massimo in termini di performance, vista la necessità di inizializzare ogni texture con initializeOpenGLFunctions(). |
| |
| L'alternativa è quella di fare a meno di QOpenGLTexture invocando direttamente i comandi OpenGL delle texture (glGenTextures, glBindTexture, glDeletetexture ... ). A volte il modo migliore di risolvere i problemi è eliminarli! | L'alternativa è quella di fare a meno di QOpenGLTexture invocando direttamente i comandi OpenGL delle texture (glGenTextures, glBindTexture, glDeletetexture ... ). A volte il modo migliore per risolvere i problemi è eliminarli alla radice! |
| |
