viele, kurze strings in einem View zeichnen ist sehr langsam

  • Original von Tom9811
    Das Problem dürfte bei den Glyphen liegen. Da muss man aufpassen. Ein Zeichen = Ein Glyph geht ziemlich in die Hose.


    jo, das dürfte meist in die hose gehen weil char:glyph = n:n.
    wenn man aber zb nur ziffern darstellen würde dann kann man sich recht sicher sein dass 1 genau ein glyph ist und 2 auch und 3 etc... folglich könnte man sich vernünftig zahlen zusammenbasteln...
  • Das zeichnen von Bildern ist deshalb schneller, weil nur ein Blit gemacht werden muss bzw. in einem PDF ja gar nicht gerendert werden muss.

    Verstehe ich dich richtig, dass es dir um die schnelle Ausgabe in ein PDF geht?
    Es hat noch nie etwas gefunzt. To tear down the Wall would be a Werror!
    25.06.2016: [Swift] gehört zu meinen *Favorite Tags* auf SO. In welcher Bedeutung von "favorite"?
  • Original von Tom9811
    Das zeichnen von Bildern ist deshalb schneller, weil nur ein Blit gemacht werden muss bzw. in einem PDF ja gar nicht gerendert werden muss.

    Verstehe ich dich richtig, dass es dir um die schnelle Ausgabe in ein PDF geht?


    wenn das rendern der bilder zu langsam gewesen wäre dann hätte ich eben danach gefragt - das problem ist aber der beschreibende text.
    Ja, es geht mir darum etwas EINMAL zu zeichnen ohne es im programm selbst zu sehen - also es direkt exporteiren.
  • Original von gritsch
    ich hab mal ein example gemacht.

    ist ja pervers wie langsam die pezierpaths sind:

    Nur ein kleiner Nebensenf: Wie langsam _ein_ Bezierpath ist. Wenn Du alle Teile in einen BP packst, muss es langsam sein. Die Renderzeit von Bezier Paths skaliert normalerweise quadratisch mit der Anzahl der enthaltenen linearisierten Pfadsegmente, weil paarweise Schnitte berechnet werden müssen. Das dürfte in Deinem Beispiel den Bärenanteil der Zeit gebraucht haben. Ich würde es mit Bezier Paths eher einzeln machen - im Gegenstatz zum Ansatz ohne, wo ich versuchen würde, nicht die Teile einzeln zu malen, sondern mir ein Textsystem hinzubiegen, das alles in einem Rutsch malt - das ist normalerweise auch fix.
    Multigrad - 360°-Produktfotografie für den Mac
  • Original von gritsch
    Original von Tom9811
    Das zeichnen von Bildern ist deshalb schneller, weil nur ein Blit gemacht werden muss bzw. in einem PDF ja gar nicht gerendert werden muss.

    Verstehe ich dich richtig, dass es dir um die schnelle Ausgabe in ein PDF geht?


    wenn das rendern der bilder zu langsam gewesen wäre dann hätte ich eben danach gefragt - das problem ist aber der beschreibende text.
    Ja, es geht mir darum etwas EINMAL zu zeichnen ohne es im programm selbst zu sehen - also es direkt exporteiren.
    Hast Du schon mal drüber nachgedacht, überhaupt ohne Glyphs zu arbeiten und das PDF "zu Fuß" zu erstellen? Das PDF-Format ist hervorragend dokumentiert...

    adobe.com/devnet/pdf/pdf_reference.html

    Und: wenn man Glyphs malen will dann gibt man z.B.

    Quellcode

    1. (abcde) "
    aus. Bilder kann man als TIFF im PDF-Dokument einbauen.

    -- hns
  • Hat es eigentlich schon jemand mit ATSUI versucht?

    hab mich da jetzt ordentlich durchgelesen weil mir ein DTS Engineer das empfohlen hatte um ein paar beschriebene Probleme (die sich als Bugs in Tiger und Leopard rausstellten) zu umgehen...
    Auf dem ersten Blick sieht das eigentlich ganz vernünftig schnell aus - ich muss es aber noch hard-core-testen ;)
  • Ich weiß nicht, ob ich das sagen darf, aber ATSUI ist mit Leopard deprecated. Da kommt ein neues Framework, dass das alles viel besser kann.

    Und die CG Methoden müssten eigentlich Unicode können. Also bei mir nutze ich das auf jeden Fall so. Du musst halt nur vorher von Char in Glyph konvertieren und dann geht das auch rasend schnell.

    Max
  • Original von M.A.X
    Ich weiß nicht, ob ich das sagen darf, aber ATSUI ist mit Leopard deprecated. Da kommt ein neues Framework, dass das alles viel besser kann.


    Das nützt mir aber unter 10.3 und 10.4 wenig. eventuell muss mans halt doppelt implementieren...

    Original von M.A.XDu musst halt nur vorher von Char in Glyph konvertieren und dann geht das auch rasend schnell.


    Aha, und wie denn?
  • Das macht dir ein LayoutManager. Ich muss nur 5 Typen von zeichen malen drum hab ich das statisch gemacht. Aber im Prinzip fütterst du ihn mit Daten und holst dir über glyphsInRange: die Glyphen, die du dann mit CGContextShowGlyphsAtPoint zeichnen kannst.

    Max
  • Original von M.A.X
    liefert der layoutManager kein korrektes Ergebnis? Und was für Bugs sind denn da drin?

    Max


    hui, gar nicht mitbekommen dass du hier noch gewntowrtet hast.
    nur um den thread vollständig zu machen:
    der layoutmanager würde zar ein korrektes ergebnis bringen, dafür würd ich aber NSFont benötigen. Und NSFont kann ich nicht verwenden weil wenn ich eine instanz davon erzeuge kann man die schrift z.b. nicht mehr deaktivieren. Habs inzwischen mit ATSUI (das zeichnen) gelöst und das mit den glyphs ”einfach" aus den tabellen geparsed.