J'ai proposé que JMP traite les éléments d'affichage de la même manière que tout autre framework GUI : ne redessinez aucun élément à moins que le contenu n'ait changé ou qu'une méthode de redessinage (ou inval) spécifique soit invoquée.
Plus précisément, peut- il y avoir un moyen d'empêcher les framebox de redessiner le contenu (cela inclut de redessiner tous les points de données et de réexécuter tout script joint) chaque fois qu'une fenêtre défile ? Sérieusement, dessinez une fois et gardez le bitmap (ou pixmap) persistant sauf si la boîte a été modifiée (changement de taille / changement dt RowState / méthode inval)
Il s’agit d’une perte de productivité incroyablement extrême lors du défilement de graphiques contenant plusieurs milliers de points ou de scripts complexes attachés. La méthode actuelle consistant à « redessiner à chaque occasion possible, quoi qu'il arrive » est extrêmement déroutante.
Voici un exemple : le script ci-joint s'imprime simplement dans le journal, mais le défilement des graphiques montre comment il s'exécute constamment à chaque mise à jour de la boîte de défilement (ne propagez pas le <
New Window( "Test",
vlb = V List Box()
);
::global function = Function( {},
Print( 1 );
);
For( i = 1, i <= 20, i++,
vlb << Append(
Graph Box(
Frame Size( 200, 200 ),
X Scale( -100, 100 ),
Y Scale( -100, 100 ),
::global function
)
)
)Merci pour la réponse!(désolé pour la réponse longue ici)
Dans mon groupe, nous examinons les défauts sur les plaquettes - nous allons souvent scanner des FOUP entiers lors d'excursions composées de 25 plaquettes.Comme il s'agit d'excursions, il y a souvent des dizaines ou des centaines de milliers de défauts par plaquette.Une partie de notre flux de travail consiste à vérifier ces plaquettes.
J'ai créé un script qui ne fait que peu de personnalisations de l'intrigue - à savoir, je dessine le dé sous les points de défaut à l'aide de la commande Path () (en utilisant une chaîne SVG), puis dessine les défauts non classés, puis ajoute un segment marqueur avec les défauts classés en dernier (pour s'assurer que les défauts classés ne sont pas masqués par les défauts non classés).
Le rendu initial de 25 wafers peut prendre plusieurs secondes et nous pouvons souvent les voir tous en même temps (taille relativement petite à l'écran par wafermap), mais si les utilisateurs veulent des wafermaps plus grands, ils devront faire défiler la liste.Le défilement à travers les wafermaps devrait être fluide car rien ne change, mais bien sûr, cela prend plusieurs secondes pour chaque mise à jour de trame.
Ma solution a été de créer une image après avoir dessiné le wafermap et de ne montrer que l'image, mais cela entraîne beaucoup de frais généraux pour assurer le redessin de l'image si l'état de la table change ou quoi que ce soit d'autre.De plus, cette méthode prend environ 3 fois plus de temps pour le rendu initial que de ne pas l'utiliser.
J'ai créé des API d'interface graphique dans mon travail précédent et la valeur par défaut était toujours une évaluation paresseuse - certes, je n'ai jamais eu à utiliser de format d'image plus grand qu'un JPEG standard (2 ^ 16 pixels par côté), mais il gèrerait systématiquement ces taille maximale JPEG sans problème et n'utilisant que quelques Mo de RAM.
Ce que je pense serait idéal, c'est de pouvoir donner à une FrameBox une sorte de message pour assurer une évaluation paresseuse du bitmap pour le moteur d'affichage, puis tout problème de RAM qui pourrait potentiellement exister en raison d'énormes bitmaps (ou pixmaps) serait laissé à la discrétion de l'utilisateur.
Voici un bon exemple du problème auquel je suis confronté: (notez que j'utilise cette méthode < douloureusement lent , et ce n'est qu'un seul GraphBox.Imaginez faire cela avec 10 à 20 d'entre eux montrant!
J'utilise un ordinateur de bureau assez décent avec 64 Go de RAM et un joli processeur à 4 cœurs.Il s'agit de JMP16 avec rendu matériel (JMP14 a également le même problème) et j'utilise un moniteur 4k, mais les utilisateurs avec des moniteurs HD standard ont les mêmes problèmes.
Names Default to Here( 1 );
table = New Table( "test table",
Add Rows( 150000 ),
<<NEW column=""></NEW>
Résumer:
- Pouvez-vous fournir une méthode d'évaluation paresseuse du bitmap du gestionnaire d'affichage ?Vous savez déjà quand un RowState change et vous fournissez déjà une méthode <
- Pouvez-vous fournir une méthode pour désactiver toute tentative de survol de texte ?Cela consomme beaucoup de cycles et est également complètement inutile dans cette situation (ou même un peu nuisible car il dessine une boîte au-dessus des points)
Et, parce que je suis frustré par ces autres problèmes mineurs depuis très longtemps, permettez-moi de faire quelques autres demandes (ofc, je ne m'attends en aucun cas à ce que vous travailliez sur ces problèmes, ce serait génial si Tu l'as fait 
- Dans JMP12, l'ordre des objets était respecté dans la FrameBox -> Personnaliser... (le menu contextuel).Plus précisément, lorsque des lignes sont sélectionnées, ces points sélectionnés peuvent être dessinés par tous les scripts graphiques ajoutés répertoriés après eux dans la liste.À partir de JMP14 (je n'ai jamais utilisé JMP13, je ne peux donc pas en parler), les points sélectionnés sont dessinés au-dessus de tout le reste.Ceci est problématique lorsqu'il s'agit de plusieurs milliers de points et qu'il est impossible d'afficher des courbes de tendance ou tout autre objet au-dessus des points s'ils sont sélectionnés.
- Cela entre vraiment en jeu lorsqu'un utilisateur sélectionne une catégorie dans la légende et que les points sont sélectionnés - tout à coup, l'utilisateur ne peut pas voir les lignes !!
- voir ci-dessous pour un code montrant ceci
- De plus, lors du dessin d'une grille (je le fais pour afficher le die dans une wafermap) sur un GraphBox, la grille n'est pas anti-aliasée.Lors de la copie de l'image dans un presse-papiers, encore une fois, l'image n'est pas anticrénelée.JMP12 ferait l'anti-aliasing et les images regardaient beaucoup mieux!
- voir ci-dessous pour une comparaison de l'anti-aliasing JMP12 et JMP14/16
Exemple de problème avec des points sélectionnés au-dessus de tous les autres éléments possibles :
Names Default to Here( 1 );
table = New Table( "test table",
Add Rows( 150000 ),
<<NEW column=""></NEW>
image du problème :
La ligne doit être tracée au-dessus des points de données.
JMP12 dessinerait dans le bon ordre :
Exemples d'anti-aliasing : (notez que ce sont de faux wafermaps qui démontrent mon propos)
JMP14/16 : Imprécran :
Image de copie JMP14/16 :
Écran d'impression JMP12 :
Image de copie JMP12 :
Merci!!
Salut @ErraticAttack -
Merci pour la suggestion - les performances sont vraiment importantes pour JMP.Certains rapports peuvent mesurer plus de 100 000 pixels. JMP ne dessine donc que le contenu actuellement visible dans une zone de défilement.Sous Windows, le défilement est optimisé pour les petites valeurs de défilement afin de copier les pixels dans la mesure du possible et de ne redessiner que le contenu "nouveau".
Pouvez-vous nous en dire un peu plus sur votre cas d'utilisation ?En particulier:
- Mac ou Windows
- Votre fenêtre se compose-t-elle principalement de plates-formes ou de graphiques personnalisés ?
- Votre script graphique fait-il beaucoup de dessin ou est-il utilisé pour d'autres tâches ?
Si vous dessinez une grande quantité de géométrie à l'aide de JSL, il peut être possible d'accélérer les choses en utilisant Display Segs (Marker Seg, Line Seg) plutôt que JSL.
