Dessin rapide utilisant NSBezierPath dessinant au moins 4000 segments

J'essaie de dessiner environ 4000-10000 segments en utilisant NSBezierPath sur chaque drawRect d'un NSView (environ une boîte de 300x300 pixels). Ceci est très lourd en ressources et prend beaucoup de temps à dessiner (relativement long).Dessin rapide utilisant NSBezierPath dessinant au moins 4000 segments

Quelqu'un peut-il suggérer un substitut pour cela? J'ai essayé d'utiliser un seul NSBezierPath pour 1000 segments à la fois, mais c'est encore trop lourd.

Je cherche des alternatives possibles. Je suis sûr que OpenGL serait plus rapide, mais je ne sais pas si je dois apprendre une nouvelle plate-forme pour faire ce dont j'ai besoin. Je suis ouvert aux suggestions.

Source

2010-12-02 David

300 x 300 = 90000 et 10000 segments ont 20000 points d'extrémité. En supposant que chaque segment est très court, disons 4 pixels, cela ajoute 40000 pixels supplémentaires. Ainsi, 50% ou plus de votre surface de dessin peut être remplie, ce qui semble très encombré. Êtes-vous sûr de ces chiffres? Ai-je tort? –

De votre second paragraphe, je suppose que ces 4000+ chemins peuvent être considérés comme des copies/instances d'une forme, n'est-ce pas? Et les apparences des segments (ou au moins un sous-ensemble d'entre eux) diffèrent-elles les unes des autres? (orientation, taille, aspect visuel, etc.) Plus loin: se chevauchent-ils? Et si oui: l'ordre z est-il important? – Regexident

L'ordre z est important, mais les segments ne sont pas des copies d'une forme. Ce sont de petits segments de ligne (de 4 à 10 pixels de longueur aléatoire). Ils diffèrent par la couleur et l'orientation et défilent dans la vue. Fondamentalement, il s'agit d'un graphe déroulant de droite à gauche ayant plusieurs segments (donc beaucoup de redessins, avec beaucoup de segments.) – David

Pas une réponse, essai juste résultats

J'ai fait une expérience simple avec Mathematica. Cette expérience nous donne une limite supérieure absolue pour votre temps, puisque je n'ai utilisé aucune optimisation, aucun GPU, un langage interprété, etc. Donc je pense que beaucoup plus d'un ordre de grandeur est réalisable.

Résultats:

Création d'un très rapide, la liste des courbes de Bézier 10.000

b = Table[ 
    {Hue[RandomReal[]], 
    [email protected][{0, 300}, {4, 2}]}, {10000}];

est parce que Mathematica n'évalue rien.

maintenant rendu:

h1 = AbsoluteTime[]; [email protected][b]; h2 = AbsoluteTime[]; Print[h2 - h1]; 

Time spent 11.8 secs

Résultat:

alt text

PS: L'intention est d'établir une base de référence de synchronisation pour notre état d'esprit.

Source

2010-12-02 20:15:54

* poke! * Haha. J'ai examiné votre réponse et j'ai été très attristé par les résultats. Je suis encore là. En tant que mise à jour, j'ai découvert que le plus gros problème de ressources était la création de l'objet NSBezierPath. En outre, l'appel du message "AVC" vide les cycles majeurs. Ce problème a été résolu en 1) instanciant une seule instance de NSBezierPath, et 2) en appelant une fois le même message après que tous les moveTo/lineTo aient été placés. Cela a accéléré le traitement par un facteur d'infini (donner ou prendre 1%). Il faut moins de 0,003 secondes pour dessiner 10k segments de ligne, ce qui est tout à fait correct dans mon livre. – David

Merci pour vos réponses. Aussi, je pense que la raison pour laquelle Mathematica prend tant de temps est parce que c'est un langage d'interprète. Cela ne devrait vraiment pas prendre autant de temps. Ou, il dessine un seul segment à la fois (extrêmement consommateur) au lieu de dessiner l'image finie une fois. – David

@David Heureux de vous entendre résolu votre problème! Quant à la raison pour laquelle Mathematica a pris tant de temps, c'est clair: je l'ai fait de la façon la plus simple, sans rien optimiser, juste pour pouvoir fixer un temps de référence, car vous n'avez mentionné aucune mesure de performance. –

Dessin rapide utilisant NSBezierPath dessinant au moins 4000 segments

Répondre

Questions connexes