Discussion :

[0x4e84]

Bonsoir amis Qt-istes,

Au vu des participations déjà annoncées, le niveau du défi s'annonce élevé, et c'est d'autant plus motivant!
Le sujet se prête à de belles expérimentations et implique l'utilisation de nombreuses techniques de Qt.
Nous allons aussi tenter notre chance, ne serait-ce que pour apprendre...

Nous participons à deux. Luthin se joint à moi pour le design (il m'avait déjà bien aidé pour le défi Buddhabrot).

Notre idée: un client léger, une interface simple et épurée, réalisée avec Qt Quick. C'est le côté serveur qui se chargera de fournir les images, y compris le rendu 3D. Pour le reste, on décidera au fur et à mesure... En attendant... au travail!

Ah, oui... le nom de l'application! Ce sera "Dr. Cute" et "Mr. Hyde", pour le client et le serveur respectivement (clin d'oeil à R.L. Stevenson, et surtout au grand Serge!).


0x4e84 & Luthin

[johnlamericain]

Bienvenue dans la compétition et bon courage à tous les deux !

[gbdivers]

Bon courage !

Un choix intéressant de générer les images côté serveur. Comment pensez vous gérer les animations fluides en cas de latence réseaux ? Votre application pourra tourner hors ligne ?

[Amnell]

Un choix intéressant de générer les images côté serveur. Comment pensez vous gérer les animations fluides en cas de latence réseaux ? Votre application pourra tourner hors ligne ?

D'un autre côté, dans le principe, sauf à être branché à des dispositifs externes, je vois mal comment une app' cliente pourrait générer elle-même les informations dont elle a besoin.

[0x4e84]

Juste pour le fun, un premier rendu "fil de fer" très simpliste (vue "de haut", tous les triangles représentés, sans tenir compte des faces cachées...) du système veineux...

0x4e84

[dourouc05]

Heureusement que tu précises ce que c'est, sinon je n'aurais jamais trouvé !

[dourouc05]

Notre idée: un client léger, une interface simple et épurée, réalisée avec Qt Quick. C'est le côté serveur qui se chargera de fournir les images, y compris le rendu 3D. Pour le reste, on décidera au fur et à mesure... En attendant... au travail!

Ça me semble une belle idée de départ. Maintenant, côté serveur, il ne faut pas oublier que l'on peut avoir énormément de donnée à gérer (envoyer un cliché RX en JPG, ça ne sera pas forcément le meilleur si on doit un peu zoomer, par exemple), il faut que le serveur tienne le coup, le réseau aussi... Mais les périphériques auxquels peut être destinée l'application ne sont pas forcément très puissants (un smartphone ne pourra pas faire du ray tracing...), je suppose que c'est dans cette optique que tout sera généré côté serveur.

Bon courage !

[0x4e84]

Si le temps de latence du réseau est un problème potentiel, le temps de latence du forum Qt-DVP est en tout cas extrêmement court!

Bienvenue dans la compétition et bon courage à tous les deux !

Merci!

Un choix intéressant de générer les images côté serveur. Comment pensez vous gérer les animations fluides en cas de latence réseaux ? Votre application pourra tourner hors ligne ?

La faisabilité du concept reste encore à démontrer, bien-sûr, et il y aura un gros travail d'optimisation à effectuer (d'autant plus un défi que je pars avec absolument aucune expérience au niveau réseau). Un cache intelligent et l'envoi d'images par "tiles" seront certainement nécessaires.
L'idée est effectivement de nécessiter une connexion permanente au réseau (à moins que celà soit en contradiction avec les exigences du défi), mais en cas d'interruption, les données en cache seront toujours accessibles.

Ça me semble une belle idée de départ. Maintenant, côté serveur, il ne faut pas oublier que l'on peut avoir énormément de donnée à gérer (envoyer un cliché RX en JPG, ça ne sera pas forcément le meilleur si on doit un peu zoomer, par exemple), il faut que le serveur tienne le coup, le réseau aussi...

Merci dourouc05 pour les encouragements.
Oui, je suis bien conscient de la charge au niveau du réseau, et il va me falloir trouver des moyens d'optimiser le tout...
D'un autre côté, je pars dans l'optique d'une application pour l'hôpital "du futur", et j'imagine que les débits que supporteront les réseaux vont continuer à augmenter de manière drastique dans le futur...
D'où la décision de focaliser sur l'hypothèse d'un terminal mobile minimaliste en termes de puissance de calcul (tablette, smartphone...). Cela permettrait aussi de limiter le coût de déploiement...

Mais les périphériques auxquels peut être destinée l'application ne sont pas forcément très puissants (un smartphone ne pourra pas faire du ray tracing...), je suppose que c'est dans cette optique que tout sera généré côté serveur.

Yep, exactement, je suis parti dans cette idée.
Après la théorie, on va essayer de passer à la pratique, maintenant!...


A+!

0x4e84