C'est comme ça que l'informatique fonctionne : (c'est schématique, il est tard)
En bas tu as des transistors, tu peux les controller en leur envoyant des signaux électriques sur pleins d'entrées. Mais c'est pas pratique. Alors on laisse cela aux spécialistes.
Les spécialistes ils prennent beaucoup de transistors, et ils t'en font des ALU, de la RAM, ... qui sont des choses avec moins d'entrées, moins de sorties, de plus haut niveau, ... Mais c'est toujours dur, alors on laisse les spécialistes s'en occuper.
Les spécialistes, ils prennentce composants, et ils écrivent un OS. Ca permet de diriger ce qu'il y a en dessous à partir d'un nombre assez restreint d'opérations. Mais c'est toujours compliqué, ...
etc, etc,
Un ordinateur est un empilement de couches, et ça marche comme cela depuis un moment. Les couches ne sont pas là pour allourdir le système, et si elles le font, c'est pour faciliter la vie de l'utilisateur de la couche supérieure. Gnome et KDE, ce sont avant tout des frameworks de dévellopement, te permettant de réaliser une application en te concentrant le plus possible sur la couche métier de ton application. De plus, grâce à cela, il est possible que ton application soit portable, sans faire le moindre effort, si ce n'est utiliser uniquement des fonctions définies dans la dernière couche (modulo bien sur le fait que la couche choisie ait été porté sur plusieurs architecture)
Enfin, tout ça pour dire que personnelementje ne trouve pas nécessairement cela dommage ;-)
Ensuite, sur la question de la performance, je ne sais pas, phonon par exemple est sencé être uniquement de la colle entre l'appli est un backend. La suite n'est qu'une imaginationde ma part, mais me semble plausible :
Le backend et phonon n'ont certainement pas trop de différence de fonctions (je ne connait pas bien le domaine, mais les différents backend sonores doivent se ressembler au niveau des fonctions présentées dans leurs API. Phonon devrait donc présenter aussi la même structure. Supposont que le BE a ait une fonction play(FILE *fichier) et le BE b une fonction joueFichier(char *cheminFichier). PhononFrontend présentera une fonction joue(QString chemin)
De plus, la classe PhononFrontend aura un attribut private PhononBackend pbe, possédent une méthode joue(QString chemin). Bien sur, on a
PhononFrontend::joue(QString chemin) {
pbe.joue(chemin)
}
A l'initialisation de l'appli (ou à l'initialisation du son) le backend (pbe) est initialisé. Cela ne prend pas beaucoup plus de temps que d'initialiser uniquement le backend a ou b.
Ensuite, à l'appel de joue(), on a en plus :
dans le cas du BE a : l'appel à la fonction délégée, un open(chemin), et un appel à la fonction du backend (le open aurait de toute façon du être appelé)
dans le cas b, l'appel à la fonction déléguée et l'appel à la fonction du BE.
Bien sur, le mapping phonon-backend est certainement légèrement plus compliqué, mais ce qu'il faut voir, c'est que le traitement d'un flux audio (lecture, décodage) est certainement _beaucoup_ plus lourd que la délégation de quelque fonction d'adaptateur.
Enfin, voila, c'est mon impression, j'ai peut-être tout faux.
[^] # Re: Ce qui est dommage
Posté par Nicolas Schoonbroodt . En réponse au journal Phonon et gstreamer : un voyage dans le temps. Évalué à 10.
C'est comme ça que l'informatique fonctionne : (c'est schématique, il est tard)
En bas tu as des transistors, tu peux les controller en leur envoyant des signaux électriques sur pleins d'entrées. Mais c'est pas pratique. Alors on laisse cela aux spécialistes.
Les spécialistes ils prennent beaucoup de transistors, et ils t'en font des ALU, de la RAM, ... qui sont des choses avec moins d'entrées, moins de sorties, de plus haut niveau, ... Mais c'est toujours dur, alors on laisse les spécialistes s'en occuper.
Les spécialistes, ils prennentce composants, et ils écrivent un OS. Ca permet de diriger ce qu'il y a en dessous à partir d'un nombre assez restreint d'opérations. Mais c'est toujours compliqué, ...
etc, etc,
Un ordinateur est un empilement de couches, et ça marche comme cela depuis un moment. Les couches ne sont pas là pour allourdir le système, et si elles le font, c'est pour faciliter la vie de l'utilisateur de la couche supérieure. Gnome et KDE, ce sont avant tout des frameworks de dévellopement, te permettant de réaliser une application en te concentrant le plus possible sur la couche métier de ton application. De plus, grâce à cela, il est possible que ton application soit portable, sans faire le moindre effort, si ce n'est utiliser uniquement des fonctions définies dans la dernière couche (modulo bien sur le fait que la couche choisie ait été porté sur plusieurs architecture)
Enfin, tout ça pour dire que personnelementje ne trouve pas nécessairement cela dommage ;-)
Ensuite, sur la question de la performance, je ne sais pas, phonon par exemple est sencé être uniquement de la colle entre l'appli est un backend. La suite n'est qu'une imaginationde ma part, mais me semble plausible :
Le backend et phonon n'ont certainement pas trop de différence de fonctions (je ne connait pas bien le domaine, mais les différents backend sonores doivent se ressembler au niveau des fonctions présentées dans leurs API. Phonon devrait donc présenter aussi la même structure. Supposont que le BE a ait une fonction play(FILE *fichier) et le BE b une fonction joueFichier(char *cheminFichier). PhononFrontend présentera une fonction joue(QString chemin)
De plus, la classe PhononFrontend aura un attribut private PhononBackend pbe, possédent une méthode joue(QString chemin). Bien sur, on a
PhononFrontend::joue(QString chemin) {
pbe.joue(chemin)
}
A l'initialisation de l'appli (ou à l'initialisation du son) le backend (pbe) est initialisé. Cela ne prend pas beaucoup plus de temps que d'initialiser uniquement le backend a ou b.
Ensuite, à l'appel de joue(), on a en plus :
dans le cas du BE a : l'appel à la fonction délégée, un open(chemin), et un appel à la fonction du backend (le open aurait de toute façon du être appelé)
dans le cas b, l'appel à la fonction déléguée et l'appel à la fonction du BE.
Bien sur, le mapping phonon-backend est certainement légèrement plus compliqué, mais ce qu'il faut voir, c'est que le traitement d'un flux audio (lecture, décodage) est certainement _beaucoup_ plus lourd que la délégation de quelque fonction d'adaptateur.
Enfin, voila, c'est mon impression, j'ai peut-être tout faux.