GTK e API su Windows

[NERO23]

Linguaggio C

Finestre con API e GTK.
In termini di prestazioni, quale delle due librerie prevale?

Volendo creare una finestra con sopra un Datagrid, ￜ possibile farlo con
le API e con le GTK?

Ciao

nero23

[Manlio Perillo]

Il Sat, 13 Apr 2013 08:52:34 +0200, NERO23 ha scritto:

> Linguaggio C
>
> Finestre con API e GTK.

API?
Quale API?

http://en.wikipedia.org/wiki/Application_programming_interface


> [...]


Ciao Manlio

[Vincenzo Mercuri]

[..]

Quoto.. anche se più su ha parlato di Windows XP e 7, quindi immagino
si riferisse alle API native win32. In questo caso, anzi in generale,
le API native del sistema operativo offrono migliori performance.
Certo su un desktop moderno non mi farei problemi..

--
Vincenzo Mercuri

[Manlio Perillo]

Il Sat, 13 Apr 2013 18:53:05 +0200, Vincenzo Mercuri ha scritto:

> [...]

> In questo caso, anzi in generale, le
> API native del sistema operativo offrono migliori performance.

Non è detto.
Ad esempio la libreria grafica delle Qt ha delle routine grafiche molto
ottimizzate.
E per cose come il DataGrid widget, magari una libreria non nativa usa
algoritmi più efficienti.

> Certo su
> un desktop moderno non mi farei problemi..

Sicuramente.


Ciao Manlio

[Vincenzo Mercuri]

On 13/04/2013 18:46, Manlio Perillo wrote:
> Il Sat, 13 Apr 2013 18:53:05 +0200, Vincenzo Mercuri ha scritto:
>
>> [...]
>> In questo caso, anzi in generale, le
>> API native del sistema operativo offrono migliori performance.
>
> Non è detto.
> Ad esempio la libreria grafica delle Qt ha delle routine grafiche molto
> ottimizzate.
> E per cose come il DataGrid widget, magari una libreria non nativa usa
> algoritmi più efficienti.
>

Sono un amante delle Qt, grazie a queste magnifiche librerie ho potuto
implementare il mio ultimo progetto. Ma tutto ciò che non è nativo è un
wrapper che si poggia alla base sulle librerie native (a meno che sia
scritto in assembly). Con questo non voglio dire che userei le librerie
native anche in caso siano necessarie performance "estreme". Non per
altro, implementare le stesse funzionalità che trovo con le Qt sarebbe
enormemente dispendioso in termini di tempo, e forse anche performance,
in quanto le Qt sono architettate meglio di come farei io (a parte quella
cosa brutta che hanno chiamato "moc" che francamente è l'unica cosa che
rende tutto più complicato). Come tu hai detto sono "molto ottimizzate",
ma sotto al cofano ci sono sempre le win32. A proposito, avevo scritto
poche righe guida sulla compilazione delle Qt5 a 64-bit per Windows con
MSVC 2010 e Qt4 a 64-bit (versione static) con l'Intel Compiler:
http://www.holoborodko.com/pavel/2011/02/01/how-to-compile-qt-4-7-with-visual-studio-2010/

--
Vincenzo Mercuri

[Manlio Perillo]

Il Sat, 13 Apr 2013 21:54:22 +0200, Vincenzo Mercuri ha scritto:

> On 13/04/2013 18:46, Manlio Perillo wrote:
>> Il Sat, 13 Apr 2013 18:53:05 +0200, Vincenzo Mercuri ha scritto:
>>
>>> [...]
>>> In questo caso, anzi in generale, le
>>> API native del sistema operativo offrono migliori performance.
>>
>> Non è detto.
>> Ad esempio la libreria grafica delle Qt ha delle routine grafiche molto
>> ottimizzate.
>> E per cose come il DataGrid widget, magari una libreria non nativa usa
>> algoritmi più efficienti.
>>
>>
> Sono un amante delle Qt, grazie a queste magnifiche librerie ho potuto
> implementare il mio ultimo progetto. Ma tutto ciò che non è nativo è un
> wrapper che si poggia alla base sulle librerie native (a meno che sia
> scritto in assembly).

Qt si appoggia alle librerie native solo per le operazioni base. Ma lo
stesso vale per le librerie Windows di alto livello (incluso i widgets di
base, oltre alle MFC e il resto).

Il discorso vale magari per le wxwindows, che invece sono un wrapper
attorno alle funzionalità dei vari ambienti.

> [...]


Ciao Manlio

[Vincenzo Mercuri]

Ho qualche dubbio forse su ciò che intendi con librerie native e non.
"solo per le operazioni base" suggerisce che la maggior parte delle
operazioni usano librerie non native, quindi (non credo tu stia
parlando delle librerie standard C/C++), per esclusione, se non stiamo
parlando di assembly, visto che nei sorgenti delle Qt non ce n'è traccia,
di cosa stiamo parlando? I sorgenti Qt fanno uso di un sistema di
ereditarietà fittissimo, tutto basato su libreria standard e librerie
native. Tutte queste classi ereditate da classi vengono prefissate da
"qt_" oppure "Qt". Nelle cartelle dedicate alle QtCore infatti vedi
innanzi tutto l'#include <unistd.h> e vedi anche, in "qtmain_win.cpp",
questo frammento che parla da sè:
(da /qt-everywhere-opensource-src-5.0.2/qtbase/src/winmain/qtmain_win.cpp)

/*
WinMain() - Initializes Windows and calls user's startup function main().
NOTE: WinMain() won't be called if the application was linked as a
"console"
application.
*/
#ifdef Q_OS_WINCE
int WINAPI WinMain(HINSTANCE instance, HINSTANCE prevInstance,
LPWSTR /*wCmdParam*/, int cmdShow)
#else
extern "C"
int APIENTRY WinMain(HINSTANCE instance, HINSTANCE prevInstance,
LPSTR /*cmdParamarg*/, int cmdShow)
#endif

dove WinMain è il cuore del motore gui di win32. Questo stesso sorgente
importa l'header "qt_windows.h"
(/qt-everywhere-opensource-src-5.0.2/qtbase/src/corelib/global/qt_windows.h)
che ha l' "infausto" compito di includere tutto ciò che interessa alle
win32: <windows.h>. Tutto il resto, il sistema signal-slot, il paradigma
model-viewer, il multithreading, e a maggior ragione tutto ciò che è
a livello più alto, si rifà esattamente a classi che ereditano metodi
che usano le librerie native. Ciò che non è nativo, e non è assembly, è:
libreria standard (che spesso è anche implementata con librerie native,
ma non è questo oggetto di discussione perchè qui si parla di grafica e
l'interfaccia tra drivers e display avviene tramite chiamate di sistema,
quindi librerie native), oppure è un wrapper di funzioni native. Forse è
meno diretto l'uso che Qt fa di win32, ma il punto di partenza è sempre
quello. Non c'è altro modo altrimenti di visualizzare GUI sullo schermo
(se non tramite routine in assembly che parlino direttamente al framebuffer
della scheda video e alla ram video).

Ciao : )

--
Vincenzo Mercuri

[NERO23]

> Quoto.. anche se più su ha parlato di Windows XP e 7, quindi immagino

> si riferisse alle API native win32. In questo caso, anzi in generale,
> le API native del sistema operativo offrono migliori performance.
> Certo su un desktop moderno non mi farei problemi..

Conosci un sito dove tratta le performance delle varie librerie su Windows?


Essendo scritte entrambe in C (GTK e Win32 API), cosa rende più
performante le API rispetto alle GTK?

Grazie

[Manlio Perillo]

Il Sun, 14 Apr 2013 00:44:34 +0200, Vincenzo Mercuri ha scritto:

> [...]
>>

> Ho qualche dubbio forse su ciò che intendi con librerie native e non.

Nel caso su cui stiamo discutendo, con native intendo le API per
l'interazione con il window manager, che qualsiasi codice che crea una GUI
deve usare per interagire con il sistema. Possiamo anche includere le
funzioni base per disegnare sullo schermo.

Facendo un caso forse più noto, come un sistema UNIX, per librerie native
intendo quelle che offrono accesso alle funzioni del kernel.

> [...]

Ciao Manlio