Discussion :

[Stef.web]

Bonjour

J'aimerai optimiser mon affichage qui lag énormément.
J'ai plusieurs onglets sur un TabPagger (composant de chez TMS) qui équivaut à un TabControl avec PageControl.
J'ai un beaucoup de composants qui fait que ça refresh lentement à chaque changement d'onglet.
Si quelqu'un à un piste pour optimiser ça je suis preneur.
A savoir que j'ai déjà tenté le DoubleBuffered sans effets!!!

Merci par avance.

Amicalement

Stéf

[ShaiLeTroll]

As-tu beaucoup de Dessin manuel ?
Des chargements manuels autre que DBControls ?

Sinon, déplace chaque onglet dans chacun leur TForm, avec un TTabControl qui ne gère que de simple onglets et non comme le TPageControl qui gère les onglets comme des container
Au changement de Page, tu libère la TForm ancrée (Parent, Align alClient, BorderSyle bsNone), et recrée une nouvelle un TForm
Cela fait beaucoup moins de contrôle !

Perso, j'ai eu des Ecrans ayant 10 onglets et plus d'un millier de contrôle (le plus dans les génomes des virus), par contre, les contrôles de ces écrans n'avaient pas de références liées, la DFM était généré par XML\XSLT et charger dynamiquement par TStream.ReadComponent

J'ai une application à Bordel avec 20 onglets et 300 composants, ce ne souffre pas de lenteur

[Stef.web]

Peux-tu me donner un simple bout de code pour être plus explicite?
La majorité des composants sont des composants tiers de chez TMS software et j'ai un onglet avec un AdvDBGrid. Ils sont en partie graphique.

[Stef.web]

En fin de compte j'ai bien relu ton message.
Parfois je comprend vite mais faut m'expliquer longtemps .

Donc, je ne peux pas utiliser plusieurs TForm car les onglets ont des fonctionnalités toutes liées entre elle. Je n'ai pas de dessin manuel, il sont tous automatique ou en dur dans les composants utilisés. Et une Bdd access chargée au démarrage du programme avec uniquement une seule et unique table de 1 à 20K enregistrements.

Par contre, j'avais il a de ça un certain temps, presque 20 ans quand même (aie ça pique) développé un appli sous dos en mode texte en turbo Pascal. Pour passer d'un menu à l'autre et optimiser mes rafraichissements, je faisais des copies rapide de ma ram vidéo dans cette même ram à une autre adresse avec des rappels pour le retour des menus imbriqué pour ne pas tout redessiner.
Maintenant si je fais ça pour du delphi, je n'ai jamais essayé, mais serait-il possible de fait une copie du canvas et court-circuiter la méthode refresh de base afin d'y applique le même principe précédemment expliqué?
Je ne fais pas du tout de code de composants, je n'est donc pas du tout d'expérience à ce niveau.

Merci par avance.

Amicalement

Stéf

[ShaiLeTroll]

Donc, je ne peux pas utiliser plusieurs TForm car les onglets ont des fonctionnalités toutes liées entre elle.

Mauvaises excuses, une programmation POO séparant la Vue et le Modèle doit permettre le stockage des données indépendamment de la présentation (changement d'onglet)
Ces données pouvant être les données réelles ainsi que des Meta-Donnée sur l'IHM (quoi qu'un système de calcul de cohérence sur les données réelles devraient permettre de s'en passer)
Comme par exemple, selon une Valeur de Tab1, je suppose que tu changes l'affichage en jouant sur Visible, Enabled ... dans des Edit de Tab2

Avec une approche basique, avec un ou plusieurs TDataset, tu peux avoir des fenêtres composées de TDBEdit, TDBGrid ... lors du changement d'onglet, tu passes à la form les TDataSource nécessaires, les modifications dans les DB Controls seront apportées aux TDataSet (en mode Edit), tu peux sans soucis libérer une Form pour entre utiliser une autre !
Un autre objet sera là pour gérer l'interaction au besoin, même si la Form doit être capable d'appliquer ses règles de gestion à la lecture des données

Il faut revoir ta conception au niveau architecture et la lourdeur de tes IHM !

[Stef.web]

Mauvaises excuses, une programmation POO séparant la Vue et le Modèle doit permettre le stockage des données indépendamment de la présentation (changement d'onglet)...

Malheureusement si bonne excuse, l'application est que ce n'est pas un client de base de données. C'est une application multimedias (genre lecteur audio d'une part sur un onglet, vidéo avec preview temps réel sur un autre qui utilise la Bdd pour avoir un classement et une recherche des dites vdéos, une playlist, une gestion d’éclairage DMX et une dernière de config) qui utilise des composants directshow (barre de progression de temps par exemple) du DSPACK.

Il est cependant vrai que je pourrai optimiser car c'est un peu, je le reconnais, coder avec les pieds à certain endroits, mais je ne peux pas tout recoder.
Cela fonctionnait parfaitement avant, mais pour faire évolué le design, je suis passé par des composants récemment acheté, ceux de chez TMS!!!


Voila pour l'historique.

Je suis quand même excusé? ;-)

Enfin, j'ai fait des tests avec des copier/coller de plein de composants sur des tabs et des forms pour simuler le problème et ça ne change rien. Je dois vraiment optimiser le refresh graphique.

[ShaiLeTroll]

Tu utilises DirectShow et TMS et tu réponds "Non" à la mention dessin manuel
C'est vrai, c'est implicite, le dessin est lié au composant mais cela reste lourd !
TMS passe son temps à dessiner ses propres effets et thèmes !
DirectShow, je l'utilise aussi pour la vidéo, ça consomme (surtout si tu en a plusieurs en même temps, mon poste avec 16 caméras c'est 100% CPU, et il a vraiment du mal à réagir)

La DBGrid affiche combien d'enregistrement ?
TAdvDBGrid normalement pas trop de problème
TAdvDBStringGrid, obsolète, était plus souple mais recopiais les données

TMS provoque pas mal de traitement, au niveau du Parent du composant, j'avais un peu fouillé, trop de mélange de TAdvComboBox, de TAdvGrid qui semblait alourdir la WndProc !

Effectivement, cela doit être assez lourd, c'est souvent le problème des logiciels de montage, de spectacle ou pyrotechnique

Tu es donc excusé, tu t'occupes d'un logiciel assez costaux, il te faut traquer ce qui est le plus lent !
Sinon, le modèle séparé de la présentation ce n'est pas que la BDD, tu peux aussi l'appliquer au multimédia, pourquoi charger des séquences vidéos en mémoire si tu es en train de configurer tout autre chose !
Pratique le LazyLoading au plus que possible, et dès qu'une ressource n'est plus utile, libère là (un système de cache peut-être utile, si tu utilises BCP de RAM, gérer soit même un fichier de travail est plus rapide que de laisser le SWAP débordé !)

Une solution qui ne corrige pas le problème mais évite l'impatience de l'utilisateur, c'est une fenêtre de progression lors du changement d'onglet pour montrer que le temps de traitement en normal !

[Stef.web]

Tu utilises DirectShow et TMS et tu réponds "Non" à la mention dessin manuel
C'est vrai, c'est implicite, le dessin est lié au composant mais cela reste lourd !

Désolé, comme je t'ai déjà dit plus haut, je ne code pas de composants, je n'avais pas compris ça . Je devrai surement m'y mettre, cela m’éviterai les soucis que j'ai maintenant mais je n'ai réellement pas le temps de mettre les mains dans le "cambouis". ;-)

TMS passe son temps à dessiner ses propres effets et thèmes !
DirectShow, je l'utilise aussi pour la vidéo, ça consomme (surtout si tu en a plusieurs en même temps, mon poste avec 16 caméras c'est 100% CPU, et il a vraiment du mal à réagir)

Pour mon utilisation, et en fonction du codec, même avec un petit CPU, avec la preview en route, un FFT pour un pseudo analyseur de spectre audio et un piste musique en plus en route je ne dépasse pas les 30% de CPU usage.

La DBGrid affiche combien d'enregistrement ?

En fonction des clients ça tourne en 1 000 et 5 000. Pour ma base de test j'en ai environ 20 000. Un TdbTable est un peu plus lent à partir de 10 000 records mais j'attaque une base Access et c'est quand je change d'index. C'est donc tout à fait normale.

Tu es donc excusé, tu t'occupes d'un logiciel assez costaux, il te faut traquer ce qui est le plus lent !

Ce qui est vraiment lent, c'est surtout ce foutu changement d'onglet qui redessine tous les composants...

Sinon, le modèle séparé de la présentation ce n'est pas que la BDD, tu peux aussi l'appliquer au multimédia, pourquoi charger des séquences vidéos en mémoire si tu es en train de configurer tout autre chose !
Pratique le LazyLoading au plus que possible, et dès qu'une ressource n'est plus utile, libère là (un système de cache peut-être utile, si tu utilises BCP de RAM, gérer soit même un fichier de travail est plus rapide que de laisser le SWAP débordé !)

Une solution qui ne corrige pas le problème mais évite l'impatience de l'utilisateur, c'est une fenêtre de progression lors du changement d'onglet pour montrer que le temps de traitement en normal !

La libération de mémoire à la volé aucun intérêts, ça ne dépasse jamais les 150Mo de ram. Le chargement de vidéo est rapide car je conseil d'utiliser du WMV, et là pas besoin de barre de progression ni de pré-chargement.
C'est avant tout un soucis esthétique. C'est pour moi impossible de faire une release qui lag à mort à chaque changement de tabs....
Ce qui m'affole le plus, j'ai une machine avec un quad core 2,4Ghz .... c'est pas juste un P4!!! J'ai juste une carte vidéo light une geForce 8400GS 512Mo, mais c'est les préconisations de bases que je donne, ça doit fonctionner au minimum avec un truc comme ça....

Je vais continuer pour voir si je peux mettre en cache mes onglets et leur interdire un refresh global.
As-tu déjà fait un truc dans ce genre de ton coté?

[ShaiLeTroll]

Pas au changement d'onglet
Sur un logiciel qui chargeait parfois 10 onglets et au moins 400 DB Controls pour 1 seule ligne de 1500 colonnes (500 triplets valeur-TimeStamp-Etat) pour gérer une traçabilité absolue lié au métier), le chargement était un peu long mais il était particulier, un BLOB contenait un XML, avec XSLT cela transformait en DFM, cette dernière chargée à la volée (pas une ressource en Dur car chaque client était libre de configurer ses données et écrans)
Un autre XML contenait aussi un complément d'historique (Hint HTML) fusionné via le XSLT !
Mon responsable avait eu des grandes idées et le développeur précédent avait fait un beau travail, la volumétrie augmentant, un petit nettoyage de code (pour économiser la mémoire) et une barre de progression, et les clients ont cru que c'était plus rapide (juste parce que l'appli ne semblait pas figer pendant 2 à 5 secondes)

Après, le changement d'onglet était instantané, il n'y avait que des CheckBox, Radio, Button, Edit, Combo de TMS
Aucun LAG à ce moment (et pourtant un système maison de Hint par thread pour les afficher sur les contrôles disabled, le Hint ayant un bouton pour les activer ou desactiver)

Il est normal au changement d'onglet que le dessin se produise des nouveaux composants actifs !
Cela fait cela pour TOUS les onglets ou certains ?
Rien de trop lourd durant le OnChange ?

Tu as essayé un TPageControl normal ? Juste pour les perfs
Idem, une TDBGrid normale ...

[Stef.web]

Il est normal au changement d'onglet que le dessin se produise des nouveaux composants actifs !
Cela fait cela pour TOUS les onglets ou certains ?

Pour tous les onglets, j'ai mis un pj pour que tu vois juste le player audio. Il n'est pas super complexe en plus!!!

Rien de trop lourd durant le OnChange ?

Rien tout cour maintenant depuis le nouveau design....

Tu as essayé un TPageControl normal ? Juste pour les perfs
Idem, une TDBGrid normale ...

Avec un TPageControl c'est à peine mieux. Pour faire le test j'ai mis plein de copier/coller de composants TMS.
Pour le TDBGrid, c'est le composant TMS qui fonctionne mieux quand il est paramétré comme il se doit

[Stef.web]

Finalement c'est le tAdvSmoothTabPage qui lag.
J'ai fait un test avec un TjvPageControl de la JVCL et maintenant j'ai des perf acceptables.
Avec le TpageControl delphi ça lag aussi bizarre quoi!!!

L'essentiel c'est que je peux continuer mon design et mon code trankilou ;-)

Merci pour tes conseils et les idées de piste

@ ++

Amicalement

Stéf