Malen unter Cocoa

Das Problem bei der Apple-Doku ist, dass sie sehr theoretisch ist. Sie ist super, wenn man das schon einigermaßen verstanden hat, für einen totalen Neuling aber anstrengend.

Wenn du mir ein Renderer mit Rulers, Scrolling, Fonts, Color, Sizing, Spell-Checking, Graphik.Einbindung ... schickst, die 5 bis 10 mal schneller ist, als NSTextView & Co, bekommst du von mir einen Preis.

Den darfst du sogar behalten.

nur, wenn es um ein umfangreicheres Layoutsystem geht, dann wird es in CG/ ATSUI schnell _sehr_ aufwändig. Z. B. wenn man folgendes noch haben will: Unicode Unterstützung, Mehrer Fonts und Fontattribute im Text, Editierbarkeit/ Veränderbarkeit des Textes, Copy and Paste, Scrolling etc. Da schreibt man sich die Finger wund und dusselig in Xcode, nur um das zu erreichen, was es in Cocoa umsonst gibt. Ein eventuell zu erhoffender Geschwindigeitsvorteil wird für Texte von ansehnlich durchschnittlichem Umfang kaum diesen Aufwand lohnen.

jo, pace. Aber einwas muss ich doch noch zur Verteidigung anbringen: Der Geschwindigkeitsvorteil ist immens, nicht irgendwie und erst recht nicht "von ansehnlich durchschnittlichem Umfang". Faktor 5-10 sag ich nur. Sorry, aber CoreGraphics wird von allen als wohl eine der besten und schnellsten Text rendering einiges überhaupt angesehen. Nicht zuletzt nutzt Cocoa auch nur CoreGraphics, das steht außer Frage und in sehr vielen Fällen braucht man auch nicht mehr, zumal Cocoa alles kann, was du beschrieben hast und das mit einer einzigen Funktion. Aber für einzelne Fälle kann man es nur empfehlen, es gibt nix vergleichbares und an den stellen, wo es wichtig ist, nehme ich es ungeniert

Original von Tom9811
Wenn du mir ein Renderer mit Rulers, Scrolling, Fonts, Color, Sizing, Spell-Checking, Graphik.Einbindung ... schickst, die 5 bis 10 mal schneller ist, als NSTextView & Co, bekommst du von mir einen Preis.

Den darfst du sogar behalten.

Hm, komisch oder? Du hast nicht richtig gelesen oder dich noch nie mit NSTextView und dem TextSystem beschäftigt. Immer diese Angriffe. *tststs* NSTextView - oder genauer: NSLayoutManager - nutzt ausschließlich CoreGraphics, um alles Zeichnen zu erledigen. Schneller geht es nicht, wenn man das problem allgemein lösen will. Nur in _Spezialfällen_ ist eine reine CG implementation (z.B. wenn du zusätzliches Zeichen zum einen textView hinzufügen willst) einer reinen Cocoa-Lösung aus Performance Gründen vorzuziehen. Es ging hier darum, dass die Methoden drawString:withAttributes: oder nur drawString: einen gigantischen Overhead produzieren (erzeugen bei jedem Aufruf ein komplettes cocoa text system mit allem drum und dran), den man in vielen Fällen sehr sehr schmerzlich zu spüren bekommt.

Wenn ich tsunamix zitieren darf: pace

Max

Quartz ist ein C-API, also kann man es direkt nur mit C ansprechen. Du kannst aber auch einfach die Cocoa-Klassen verwenden die ja, mal ganz grob und platt gesprochen, die Objective-C-Schnittstelle zu Quartz darstellen. Du kannst Quartz also so gesehen auch mit Objective-C ansprechen.

Michael

ja, manche CoreGraphics Sachen nehmen auch CoreFoundation Objekte als Parameter, die sind dan wiederum häufig Kompatibel zu den Cocoa-Klassen. Aber die Aufrufe selber müssen alle, wie Michael gesagt hat, in C geschrieben werden.

Hmmm, ich habe am Samstagabend für eine Freundin ein Karteikarten-Lernprogramm geschrieben, welches mit NSTextViews arbeitet. Hat mich etwa 6 oder 7 Stunden an den Rechner gebunden.

Das kann jetzt Absatzformatierung, Schriftarten, Schriftgrößen, Rechtschreibprüfung, Rulers, Scrolling usw usf.

Ich glaube nicht, dass du das in CG in endlicher Zeit ähnlich komfotabel und schnell programmierst, lasse mich aber gerne davon überzeugen. Das ist auch kein Angriff gegen dich, denn das dürfte niemand können.

Original von Tom9811
Hmmm, ich habe am Samstagabend für eine Freundin ein Karteikarten-Lernprogramm geschrieben, welches mit NSTextViews arbeitet. Hat mich etwa 6 oder 7 Stunden an den Rechner gebunden.

Das kann jetzt Absatzformatierung, Schriftarten, Schriftgrößen, Rechtschreibprüfung, Rulers, Scrolling usw usf.

Das ist einfach das standard-setup jedes NSTextViews wie du ihn aus der Platee im IB ziehst, das ist nichts besonderes. In Wirklichkeit verbirgt sich aber dahinter ein gigantisches textSystem aus über 10 verscheidenen klassen, die alle nur damit beschäftigt sind, alles so darzustellen, wie es sein soll...

Ich glaube nicht, dass du das in CG in endlicher Zeit ähnlich komfotabel und schnell programmierst, lasse mich aber gerne davon überzeugen. Das ist auch kein Angriff gegen dich, denn das dürfte niemand können.

Das steht ja auch nicht zu Debatte. Außerdem erübrigt sich das allein schon im Name. CoreGraphics. Das ist eine reine Grafik-Engine. Das hat nix mit Rechtschreibprüfung, Rulers und Scrolling zu tun. es stand auch nicht zu debatte, hier einen NSTextView mit CoreGraphics zu schreiben, weil der LayoutManager nämlich schon CoreGraphics nutzt. Das einzieg, was möglich wäre ist halt eine spezifische eigene Implementierung, damit man den womöglich nicht benötigten Overhead vom gesamten System los wird...

Eben, _WEIL_ es das Standard-Setup ist, aber schon alles kann, _IST_ es so komfortabel.
Um die ganzen Features einzubauen, die NSTextView von Haus aus mitbringt, hätte ich mutmaßlich ein halbes Leben benötigt. Abgesehen davon, dass ich es mutmaßlich schlechter performant hinbekommen hätte.

Das _IST_ der _VORTEIL, nicht der _NACHTEIL_

Das ist auch kein Overhead, sondern sind die _Features_.

Du kannst mittlerweile so ziemlich alles von allem ansprechen. Es ist auch möglich, USB-Treiber von Assembler aus anzusprechen.

Kurze Frage: Wozu?

Original von Tom9811
Das _IST_ der _VORTEIL, nicht der _NACHTEIL_

Das ist auch kein Overhead, sondern sind die _Features_.

komfortabel != performant
weniger Overhead != weniger Funktionalität

Es geht ja nicht drum, den kompletten TextView neu zu schrieben. Man kann den NSLayoutManager und/oder den NSTextStorage subclassen und dann die Performance verbessern. Overhead gibt es in den Zeichenroutinen einigen, wenn man z.B. nur unformatierten text darstellen will. Das wird nach attributen und gebieten für attribute gesucht, wo keine sind. Also kann man eine NSTextStorage subclass machen und attributesAtIndex: überschrieben. Oder wenn man zum NSLayoutManager weitere Funktionalität hinzufügen will (nicht druckbare Zeichen anzeigen, etc), dann verwendet man CoreGraphics. Oder wenn ich eine eigene Subclass von NSCell mache, dann überlege ich mir, ob ich Die Cocoa-Methoden oder CoreGraphics verwende. Beide sehen gleich aus, machen kaum einen Unterschied in der Implementierung sind aber X-mal unterschiedlich in der Geschwindigkeit.

Keiner will das Rad neu erfinden, aber man kann die Winterreifen aus so weiterentwickeln, dass sie bis 30° fahrbar sind *g*

Max

ich hoffe, wenigstens ihr beiden wisst noch, worüber ihr eigentlich diskutiert

ich nehme einfach mal kurz und stark an, dass der tom sich die threads immer (und vor allem: als einziger) in der baumstruktur anschaut und deshalb einfach so antwortet, ohne vorher etwas zu zitieren. Das verwirrt gewaltig, aber wir konnten es nicht ändern...

Die Ungleichung ist falsch, weil du es nicht performanter selbst hinbekommst, herjeh. OOder hast du eben eine Mannschaft von Programierern zur Hand, die das ewig coden?

Nein?

Dachte ich mir!

Aber du wirst es performanter hinbekommen als die, da bin ich mir sicher!

Dazu ist die Baumstruktur da. Ich habe ja schon bemerkt, dass du mooderne Technologien ablehnst. Die Baumstruktur gibt es alelrdings seit solanger Zeit, dass sie auch schon zu dir gedrungen sein müsste - wenngleich mich leise Zweifel erhaschen.

BTW: Komischerweise könenn die Leute, die hier wirklich Ahnung haben, damit umgehen. *Schulterzuck*

Original von Tom9811
Dazu ist die Baumstruktur da.

Wenn die wenigstens vernünftig funktionieren würde. Hier bei mir stehen alle Beiträge trotzdem schön linksbündig untereinander. Nur halt nicht in der zeitlichen Reihenfolge. Da wird nichts eingerückt. Die Zuordnung der Beiträge sieht man nur an den Links am oberen Ende, so dass ich immer hoch und runter scrollen muss, um die Übersicht zu behalten und die neuen Beiträge heraus zu fischen. Das ist unmodern.

Michael

Das ist in der Tat ärgerlich, machen aber wohl alle Foren so. Sonst würden schnell die Beiträge sehr schmal werden. Was man allerdings machen könnte -wie es etwa heise macht-, ist, dass man den zuletzt angewählten Beitrag eifärbt. So findet man ihn schnell in der Übersicht wieder.

Glülich bin ich damit auch nicht. Aber dieses einfach am Ende antworten und jeder mag sich seine Antowrt zusammensuchen, ist nun wirklich nicht komfortabler.

Alternativ könnte man natürlich auch in jedem Beitrag einen Link unterbringen: Dies ist eine Antwrt auf ... Das ist ja eine eindeutige Zuordnung.

Original von Tom9811
Die Ungleichung ist falsch, weil du es nicht performanter selbst hinbekommst, herjeh. OOder hast du eben eine Mannschaft von Programierern zur Hand, die das ewig coden?

Nein?

Dachte ich mir!

Aber du wirst es performanter hinbekommen als die, da bin ich mir sicher!

Mal eine (rein logische und verständnistechnische) Frage:

WO siehst du in der Ungleichung


impliziert, dass ich es schneller kann??

Original von Tom9811
Dazu ist die Baumstruktur da. Ich habe ja schon bemerkt, dass du mooderne Technologien ablehnst. Die Baumstruktur gibt es alelrdings seit solanger Zeit, dass sie auch schon zu dir gedrungen sein müsste - wenngleich mich leise Zweifel erhaschen.

Ich lehne neue Technologien nicht ab, ich befürworte sie. Evolution hura! Aber ich betrachte es wohl wenigstens ein klitzekleinwenig differenziert und versuch immer den schnellsten (nicht für mich, für die User, um die geht es ja) Weg zu finden. Einheitsbrei und bedingungslose Akzeptanz alles Neuen ist sinnlos. Jede Sache hat ihre Grenze und wenn es Overhead gibt oder man bestimmte techniken nicht verwenden kann/muss, weil es z.b. eine Neu-programmierung bedeuten würde, was bei einem 3-Zeilen Programm kein Problem ist, aber bei 15000 Zeilen richtig Zeit und Kopfschmerzen kostet, dann ist das nicht Ablehnung, sondern hat ganz andere gründe. Wie war das mit den angriffen??

BTW: Komischerweise könenn die Leute, die hier wirklich Ahnung haben, damit umgehen. *Schulterzuck*

<kein kommentar> *nichtgrunzundgrins*

Max