Ich habe vorgeschlagen, dass JMP Anzeigeelemente auf die gleiche Weise behandelt wie jedes andere GUI-Framework – kein Element neu zeichnet, es sei denn, der Inhalt hat sich geändert oder eine spezielle Neuzeichnungs- (oder Inval-)Methode wird aufgerufen.
Konkret: Gibt es bitte eine Möglichkeit, Frameboxen davon abzuhalten, den Inhalt neu zu zeichnen (dazu gehört das Neuzeichnen aller Datenpunkte und das erneute Ausführen aller angehängten Skripts), wenn ein Fenster gescrollt wird? Also im Ernst, zeichnen Sie einmal und behalten Sie das Bitmap (oder Pixmap) bei, sofern das Feld nicht geändert wurde (Größenänderung / dt RowState-Änderung / inval-Methode).
Dies ist ein wahnsinnig extremer Produktivitätskiller, wenn man durch Diagramme scrollt, die viele tausend Punkte oder komplexe angehängte Skripte haben. Die aktuelle Methode „bei jeder möglichen Gelegenheit neu zeichnen, egal was passiert“ ist äußerst verwirrend.
Hier ist ein Beispiel -- das angehängte Skript druckt lediglich in das Protokoll, aber das Scrollen durch die Diagramme zeigt, wie es ständig ausgeführt wird, jedes Mal wenn das Scrollfeld aktualisiert wird (propagieren Sie nicht das <
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
)
)
)Danke für die Antwort!(Entschuldigung für die langatmige Antwort hier)
In meiner Gruppe untersuchen wir Defekte auf Wafern – oft scannen wir bei Exkursionen ganze FOUPs, die aus 25 Wafern bestehen.Da es sich um Abweichungen handelt, kommt es häufig zu Zehn- oder Hunderttausenden Defekten pro Wafer.Ein Teil unseres Arbeitsablaufs besteht darin, diese Wafer zu überprüfen.
Ich habe ein Skript erstellt, das nur ein paar kleine Anpassungen am Plot vornimmt – nämlich, dass ich mit dem Path()-Befehl (unter Verwendung einer SVG-Zeichenfolge) den Würfel unter den Fehlerpunkten zeichne, dann die nicht klassifizierten Fehler zeichne und dann füge ein Markierungssegment mit den klassifizierten Mängeln zuletzt (um sicherzustellen, dass die klassifizierten Mängel nicht durch die nicht klassifizierten Mängel verdeckt werden).
Das anfängliche Rendern von 25 Wafern kann mehrere Sekunden dauern und oft können wir sie alle auf einmal sehen (relativ kleine Bildschirmgröße pro Wafermap). Wenn Benutzer jedoch größere Wafermaps wünschen, müssen sie durch die Liste scrollen.Das Scrollen durch die Wafermaps sollte butterweich sein, da sich nichts ändert, aber natürlich dauert jede Frame-Aktualisierung mehrere Sekunden.
Meine Lösung bestand darin, nach dem Zeichnen der Wafermap ein Bild zu erstellen und nur das Bild anzuzeigen. Dies führt jedoch zu einem hohen Aufwand, um das erneute Zeichnen des Bildes sicherzustellen, wenn sich der Tabellenstatus ändert oder etwas anderes.Außerdem dauert das anfängliche Rendern dieser Methode ungefähr dreimal länger, als wenn sie nicht verwendet wird.
Ich habe in meiner vorherigen Arbeit GUI-APIs erstellt und die Standardeinstellung war immer die verzögerte Auswertung – zugegebenermaßen musste ich nie ein Bildformat verwenden, das größer als ein Standard-JPEG (2^16 Pixel pro Seite) war, aber diese maximale Größe wurde routinemäßig verarbeitet JPEGs ohne Probleme und verbrauchen nur ein paar MB RAM.
Ideal wäre es meiner Meinung nach, einer FrameBox eine Art Nachricht geben zu können, um eine verzögerte Auswertung der Bitmap für die Anzeige-Engine sicherzustellen, und dann würden alle RAM-Probleme, die möglicherweise aufgrund großer Bitmaps (oder Pixmaps) bestehen könnten, bestehen bleiben liegt im Ermessen des Benutzers.
Hier ist ein gutes Beispiel für das Problem, mit dem ich mich befasse: (Beachten Sie, dass ich diese < schmerzhaft langsam , und es ist nur eine GraphBox.Stellen Sie sich vor, Sie machen das mit 10–20 davon!
Ich verwende einen ziemlich guten Desktop mit 64 GB RAM und einer schönen 4-Kern-CPU.Dies ist JMP16 mit Hardware-Rendering (JMP14 hat ebenfalls das gleiche Problem) und ich verwende einen 4K-Monitor, aber Benutzer mit Standard-HD-Monitoren haben die gleichen Probleme.
Names Default to Here( 1 );
table = New Table( "test table",
Add Rows( 150000 ),
<<NEW column=""></NEW>
Zusammenfassen:
- Können Sie eine Methode zur verzögerten Auswertung der Display Manager-Bitmap bereitstellen?Sie wissen bereits, wann sich ein RowState ändert, und Sie stellen bereits eine <
- Können Sie eine Methode bereitstellen, um jeden Versuch, Hover-Text zu senden, zu deaktivieren?Das verschlingt viele Zyklen und ist in dieser Situation auch völlig nutzlos (oder sogar ein wenig schädlich, da es ein Kästchen über den Punkten zeichnet).
Und da ich mit diesen anderen kleineren Problemen schon sehr lange frustriert bin, möchte ich noch ein paar weitere Anfragen stellen (natürlich erwarte ich keineswegs, dass Sie an diesen Problemen arbeiten, es wäre einfach großartig, wenn du machtest 
- In JMP12 wurde die Reihenfolge der Objekte in FrameBox -> Anpassen... eingehalten. (das Rechtsklick-Menü).Insbesondere können bei der Auswahl von Zeilen diese ausgewählten Punkte von allen hinzugefügten Grafikskripten gezeichnet werden, die nach ihnen in der Liste aufgeführt sind.Beginnend mit JMP14 (ich habe JMP13 nie verwendet, daher kann ich nichts dazu sagen) werden ausgewählte Punkte über alles andere gezeichnet.Dies ist problematisch, wenn es um viele tausend Punkte geht und keine Trendlinien oder andere Objekte über den Punkten angezeigt werden können, wenn diese ausgewählt sind.
- Dies kommt wirklich ins Spiel, wenn ein Benutzer eine Kategorie in der Legende auswählt und die Punkte ausgewählt werden – plötzlich kann der Benutzer die Linien nicht mehr sehen!!
- Unten finden Sie einen Code, der dies zeigt
- Auch beim Zeichnen eines Rasters (ich mache dies, um die Chips in einer Wafermap anzuzeigen) auf einer GraphBox wird das Raster nicht geglättet.Beim Kopieren des Bildes in die Zwischenablage wird das Bild wiederum nicht geglättet.JMP12 würde das Anti-Aliasing durchführen und die Bilder sahen aus viel besser!
- Unten finden Sie einen Vergleich von JMP12 und JMP14/16 Anti-Aliasing
Beispielproblem mit ausgewählten Punkten vor allen anderen möglichen Elementen:
Names Default to Here( 1 );
table = New Table( "test table",
Add Rows( 150000 ),
<<NEW column=""></NEW>
Bild des Problems:
Die Linie sollte über den Datenpunkten gezeichnet werden.
JMP12 würde in der richtigen Reihenfolge zeichnen:
Beispiele für Anti-Aliasing: (Beachten Sie, dass es sich hierbei um gefälschte Wafermaps handelt, die meinen Standpunkt verdeutlichen.)
JMP14/16: Druckbildschirm:
JMP14/16 CopyPicture:
JMP12 PrintScreen:
JMP12 CopyPicture:
Danke!!
Hallo @ErraticAttack -
Vielen Dank für den Vorschlag – Leistung ist für JMP definitiv wichtig.Einige Berichte können über 100.000 Pixel hoch sein, daher zeichnet JMP nur den Inhalt, der aktuell in einem Bildlaufbereich sichtbar ist.Unter Windows ist das Scrollen für kleine Scrollwerte optimiert, um Pixel nach Möglichkeit zu kopieren und nur den Inhalt neu zu zeichnen, der „neu“ ist.
Können Sie uns etwas mehr über Ihren Anwendungsfall erzählen?Insbesondere:
- Mac oder Windows
- Besteht Ihr Fenster hauptsächlich aus Plattformen oder benutzerdefinierten Diagrammen?
- Zeichnet Ihr Grafikskript viel oder wird es für andere Aufgaben verwendet?
Wenn Sie eine große Menge an Geometrie mit JSL zeichnen, kann es möglicherweise möglich sein, die Arbeit zu beschleunigen, indem Sie Display Segs (Marker Seg, Line Seg) anstelle von JSL verwenden.
