Hallo,
gibt es ein empfehlenswertes Bildbearbeitungsprogramm zwischen Paint und
Gimpf für Win10?
Paint ist schnell geladen, wenn man es braucht - aber man kann damit
keine weiterreichenden Sachen wie Kontrast- oder
Helligkeitseinstellungen vornehmen.
Gimpf läd ziemlich lange und ist damit nichts für schnelle
Bildbearbeitungen nebenbei. Auch, wenn der Umfang sonst super ist.
Gibt es ein empfehlenswertes Bildbearbeitungsprogramm "in der Mitte"
zwischen diesen beiden?
Mir geht es dabei in der Hauptsache um Kontrast- und
Helligkeitsänderungen.
Tim schrieb:> Gimp war gemeint, sorry.> https://www.gimp.org/
Du musst dich für deinen Typo nicht entschuldigen, alles gut.
Heinz wusste ganz genau was gemeint ist, wollte aber etwas rumnölen oder
begrenzt witzig sein.
Tim schrieb:> Mir geht es dabei in der Hauptsache um Kontrast- und> Helligkeitsänderungen.
Gerade dafür ist Gimp aber sehr schön geeignet.
Die Ladezeit derxeinzelnen Dateien ist auch nichtxweiter schlimm; nur
diexStartzeit von Gimp selbst kann etwas nerven.
Wenn Du Gimp gleich nach dem Hochfahren des Computer startest,
vielleicht auch per Autostart, solltest Du den Rest der Session kein
Problem haben.
openCanvas von PGN Co. Ltd.
Sehr empfehlenswert.
Unbegrenztes Undo/Redo.
Bearbeitungsschritte koennen aufgezeichnet werden,
und auch beim naechten Bild einfach wiederholt werden.
Percy N. schrieb:> die Startzeit von Gimp selbst kann etwas nerven
Braucht der wirklich so lange? Auf all meinen Computern startet er in
deutlich weniger als einer Sekunde. Allerdings ist kein Windows dabei.
Le X. schrieb:> Tim schrieb:>> Gimp war gemeint, sorry.>> https://www.gimp.org/>> Du musst dich für deinen Typo nicht entschuldigen, alles gut.> Heinz wusste ganz genau was gemeint ist, wollte aber etwas rumnölen oder> begrenzt witzig sein.
Wenn in der Überschrift und im Text das gleiche steht, kann man nicht
von einem Tippfehler ausgehen.
Jörg W. schrieb:> Braucht der wirklich so lange? Auf all meinen Computern startet er in> deutlich weniger als einer Sekunde. Allerdings ist kein Windows dabei.
Das hängt u. a. ganz wesentlich davon ab, wie viele Schriften man
installiert hat. Inzwischen ist aber das Staet-Konzept von Gimp
überarbeitet worden; wer keine Textfunktionen verwenden will, kann schon
arbeiten, bevor Gimp die Schriften geladen *oder was auch immer) hat.
Nervig wird es beim ersten Gimp-Start nach dem Installieren oder
Deinstallieren auch nur einer einzigen Schrift. (Alles WIN ...)
OK, beim allerersten Start nach dem Installieren (und halt
möglicherweise auch nach derartigen Änderungen) braucht er wirklich 'ne
Weile. Aber danach geht's flink.
Ich verwende Gimp auf Arbeit unter Windows und privat unter Kubuntu.
Ich wundere mich zu Hause immer wie schnell das geladen ist, ja das
dauert unter Windows durchaus 10s und länger.
Jörg W. schrieb:> Percy N. schrieb:>> die Startzeit von Gimp selbst kann etwas nerven>> Braucht der wirklich so lange? Auf all meinen Computern startet er in> deutlich weniger als einer Sekunde. Allerdings ist kein Windows dabei.
Grad getestet, 13 sekunden braucht hier die 2.10.14.
Kritischer als die Startzeit, finde ich dagegen die Einarbeitszeit, da
kann man schon mal locker ein Wochenende rechnen bis man das fachlatein
drauf hat ('Abwedeln', 'Entsättigen')
Manfred Malicious schrieb:> Abwedeln', 'Entsättigen'
Gerade das finde ich eher intuitiv erfassbar. Abwedeln kennt man aus dem
Fotolabor, und Entsättigen isr eigentlich selbsterklärend.
Im Vergleich zu FastStone ist Gimp eine furchtbar überladenes
Fenstermonster.
Ladezeiten, Übersichtlichkeit, Bedienbarkeit - 3:0 für FS
Und läuft auch per Wine prima unter Linux, kann Canons cr2 Format lesen
was für mich wichtig ist.
+1 für Irfanview. Gerade wenn man eine gewisse Anzahl Bilder hat, wo man
einfach nur etwas Helligkeit/Kontrast anpassen oder Das Bild beschneiden
will(Strg+Y), kenne ich nichts schnelleres und bequemeres. Im Bild
malen, kopierstempeln, einzelne Stellen abwedeln etc. geht damit aber
nicht.
LG, Björn
Hi,
gibt noch etwas zwischen gimp und paint: krita
https://krita.org/
ist opensource, massiv in entwicklung, und könnte demnächst noch mehr
features haben als gimp..
Tim schrieb:> Installieren oder lieber nicht???
Wenn nur ein Scanner meckert würde ich auf eine Fehlerkennung tippen.
Garantieren kann ich dafür natürlich nicht und die Entscheidung musst du
selbst treffen.
Habe paint.net schon Jahre auf dem Rechner und durch den integrierten
Updater auch immer die aktuelle Version. Bisher hat Defender nicht
gemeckert.
Manfred Malicious schrieb:> Grad getestet, 13 sekunden braucht hier die 2.10.14.
:-o
Hier auf meinem etwas angeältelten Computer zu Hause (ca. 7 Jahre alt)
braucht es um die 2 Sekunden.
> Kritischer als die Startzeit, finde ich dagegen die Einarbeitszeit, da> kann man schon mal locker ein Wochenende rechnen bis man das fachlatein> drauf hat ('Abwedeln', 'Entsättigen')
Wie schon genannt worden ist, das sind Begriffe aus der Fotografie. Die
wird man für eine halbwegs ernsthafte Bildbearbeitung brauchen.
Für bisschen Zuschneiden oder Kontrasteinstellung braucht man das
allerdingns auch im GIMP nicht.
Tim schrieb:> Habe ich gemacht und runtergeladen. Dann bekommt man die Datei> paint.net.4.2.13.install.exe.
Bei mir kommt da ein Link zu einem Zip-File...
Opfere 10 Euro und kauf dir bei Pearl Corel-Paint-Pro. Ist zwar nicht
Photoshop-Klasse aber schon weit über das was der Normal-Verbraucher
braucht.
https://www.pearl.de/a-KS802-2210.shtml
Jörg W. schrieb:> Percy N. schrieb:>> die Startzeit von Gimp selbst kann etwas nerven>> Braucht der wirklich so lange? Auf all meinen Computern startet er in> deutlich weniger als einer Sekunde. Allerdings ist kein Windows dabei.
Also bei mir startet es unter Linux zwar deutlich schneller als unter
Windows, aber längst nicht innerhalb von weniger als einer Sekunde.
Und außerdem: dass er unter Windows so überproportional lange braucht,
liegt daran, dass es mit der Portabilität von C++-Code doch längst nicht
so weit her ist, wie die einschlägigen Jubelperser immer behaupten und
daran, das der Windows-Zweig halt in Teilen schlicht absolut beschissen
geschrieben ist, geradezu idiotisch.
Lustig: man muss nichtmal ein guter Programmierer sein, um
herauszufinden, wer Schuld ist. Freundlicherweise verpetzt der
Splash-Screen ja, was gerade passiert. Mit diesen Informationen kann man
ziemlich gezielt in den Code schauen und so sehr schnell erkennen, wo
die Säge klemmt.
Das ist ganz klar Code, der ursprünglich für Linux geschrieben wurde und
dann von eher widerwilligen Programmierern auf Windows portiert wurde.
Wohl nur unter dem Zwang, dass es halt für die Verbreitung des Programms
überaus nützlich ist, wenn auch die >90% der Desktops unterstützt
werden, die halt unter Windows laufen...
Denn für ein Grafikprogramm ist es völlig irrelevant, ob Server oder
Embedded-Krams unter Linux läuft, denn da braucht niemand ein
Grafikprogramm...
Schlaumaier schrieb:> Aber nicht für 10 Euro als EWIG-Version. Sonst bestelle ich das noch> heute.
Ich habe PSP 2020 als Zugabe zu Softmaker Office bekommen, wimre.
Solo bekommst Du es derzeit für weniger als 40 Euro.
c-hater schrieb:> Und außerdem: dass er unter Windows so überproportional lange braucht,> liegt daran, dass es mit der Portabilität von C++-Code doch längst nicht> so weit her ist, wie die einschlägigen Jubelperser immer behaupten
Hmpf.
Du solltest dir vielleicht den Gimp-Sourcecode erstmal ansehen, bevor du
derartig große Bögen spuckst.
Percy N. schrieb:> Das hängt u. a. ganz wesentlich davon ab, wie viele Schriften man> installiert hat.
Unter der gleichen Krankheit scheint auch LilyPond zu leiden, btw.
Björn schrieb:> Im Bild> malen, kopierstempeln, einzelne Stellen abwedeln etc. geht damit aber> nicht.
Klar kann es das, drück mal F12! Recht rudimentär aber es geht schon
was.
Jörg W. schrieb:> Hmpf.>> Du solltest dir vielleicht den Gimp-Sourcecode erstmal ansehen, bevor du> derartig große Bögen spuckst.
Ich habe ihn mir angesehen.
Und, ohne auf Details einzugehen: allein die Tatsache, dass es MS-Office
praktisch on-the-fly schafft, auch auf Computern mit riesigem Bestand an
Fonts zügig zu starten und trotzdem sofort in den entsprechenden
GUI-Elementen alle diese Schriften (sogar mit Vorschau des jeweiligen
Erscheinungsbildes) anzuzeigen, zeigt doch überaus eindeutig, dass die
Sache bei Gimp wohl nicht näherungsweise optimal für Windows umgesetzt
worden sein kann...
Tja, Scheiße. Die normative Kraft der Fakten entlarvt die üblichen
Jubelperser als eben solche...
c-hater schrieb:> Jörg W. schrieb:>>> Hmpf.>>>> Du solltest dir vielleicht den Gimp-Sourcecode erstmal ansehen, bevor du>> derartig große Bögen spuckst.>> Ich habe ihn mir angesehen.
Offenbar nicht. Sonst wärst du nicht auf die Idee gekommen, dass es an
C++ läge. Das gibt's in den Gimp-Quellen nämlich schlicht und ergreifend
gar nicht.
Nun pack mal deine Jubelperser wieder ein …
Teo D. schrieb:> Björn schrieb:>> Im Bild>> malen, kopierstempeln, einzelne Stellen abwedeln etc. geht damit aber>> nicht.>> Klar kann es das, drück mal F12! Recht rudimentär aber es geht schon> was.
So ein Sch...
Da gets um Irfanview.... :/
c-hater schrieb:> Und, ohne auf Details einzugehen: allein die Tatsache, dass es MS-Office> praktisch on-the-fly schafft, auch auf Computern mit riesigem Bestand an> Fonts zügig zu starten und trotzdem sofort in den entsprechenden> GUI-Elementen alle diese Schriften (sogar mit Vorschau des jeweiligen> Erscheinungsbildes) anzuzeigen, zeigt doch überaus eindeutig, dass die> Sache bei Gimp wohl nicht näherungsweise optimal für Windows umgesetzt> worden sein kann...
Naja, ist halt so: die Software wurde für ein anderes System entwickelt,
und hier halt auf Windows gewürgt. Ist andersrum ja auch oft genug mit
Einschränkungen verbunden: wenn man nämlich für Windows entwickelte
Software auf Linux würgt. So what?
Unter Windows gibt’s doch das sagenumwobene „Photoshop“, mit dem jeder
Anfänger alles sofort machen kann? Las sich zumindest im Nachbarthread
so …
Jack V. schrieb:> Naja, ist halt so: die Software wurde für ein anderes System entwickelt,> und hier halt auf Windows gewürgt.
Vermutung: Gimp öffnet viele Dateien. Dateiarbeit unter Windows ist
bekanntermaßen kein Rennauto – beim Compilieren sind die Unterschiede
stets spürbar. Größere Compilerläufe auf Windows vs. irgendein Unix sind
bei gleicher Hardware massiv langsamer – und der Compiler hat kaum
systemabhängigen Code.
Tim schrieb:> gibt es ein empfehlenswertes Bildbearbeitungsprogramm zwischen Paint und> Gimpf für Win10?
Sehe ich nicht so. Aber oberhalb von beiden gibt es was: Pearl bietet
derzeit Ulead Photoimpact 11 für 4.90€ an.
W.S.
Jörg W. schrieb:> Percy N. schrieb:>> die Startzeit von Gimp selbst kann etwas nerven>> Braucht der wirklich so lange? Auf all meinen Computern startet er in> deutlich weniger als einer Sekunde. Allerdings ist kein Windows dabei.
Unter Windows ja.
Das Problem ist hier nicht Gimp, sondern GTK, Python und der sonstige
Rest, den Gimp noch braucht.
Wenn einem schnelle Startzeiten wichtig sind, dann sollte man kein
Programm einsetzen, das zusätzliche fettte Bibliotheken laden muss.
Daher ist auch der Vorschlag mit dem .Net Programm schlecht, da da ja
noch .Net geladen werden muss.
Stattdessen nimmt man besser etwas natives, dass bspw. in der WinAPI
oder MFC geschrieben wurde.
Das sollte dann recht schnelle Startzeiten unter Windows vorweisen.
P. S. schrieb:> Finde ich nicht nett, dass man für einen kleinen Tippfehler gleich so> verungimpft wird.
Da sieht man, wie ein Tippfehler den ganzen Satz urinieren kann
Nano schrieb:> das zusätzliche fettte Bibliotheken laden muss
Weiß ja nicht, wie das unter Windows ist – unter unixoiden Systemen ist
das doch alles load-on-demand. Es ist also völlig egal, ob die
Bibliotheken "fett" sind (davon abgesehen, Gtk ist wahrscheinlich von
den GUI Toolkits der schlankste), denn es wird daraus nur das geladen,
was aktuell auch wirklich vom Programm angesprochen worden ist. (Das
funktioniert über das VM-Subsystem: der erste Versuch, eine
entsprechende Adresse anzusprechen, generiert einen page fault [page not
present], das OS fängt den Trap ab, lädt die entsprechende Seite vom
disk file nach, und die Applikation setzt an der Stelle fort, wo sie den
page fault erzeugte.)
Es würde mich ehrlich wundern, wenn das unter Windows heutzutage anders
wäre.
Wie oben geschrieben: ich denke, dass das eher das Anfassen vieler
Dateien ist, bei dem Windows halt wirklich langsam ist.
Was übrigens auch völlig gegen die These vom "bösen fetten
Linux-Toolkit" spricht: ich habe gerade mal spaßeshalber den
Windows-Build von gerbv getestet. gerbv basiert ja wie Gimp auch auf dem
Gtk, es schleppt auch (zumindest hier unter meinem FreeBSD) sackweise
andere shared libs mit rein:
Percy N. schrieb:> Abwedeln kennt man aus dem> Fotolabor, und Entsättigen isr eigentlich selbsterklärend.
Das letzte mal im (Chemischen) Fotolabor ist mindestens drei Jahrzehnte
her, und nach Schwarz/weiss konvertieren" wäre selbsterklärend,
"entsättigen" ist es nicht. Ebenso "Aufhellen" statt abwedeln,
schliesslich geht es um den optischen Effekt und nicht um Bildgebenede
Verfahren aus der Steinzeit. Das 'B' für Ball/Bulb ist ja auch von der
Belichtungseinstellung entschwunden...
Zaunwinker schrieb:> Ebenso "Aufhellen" statt abwedeln, schliesslich geht es um den optischen> Effekt und nicht um Bildgebenede Verfahren aus der Steinzeit.
Das ist etwas anderes. Abwedeln umfasst insbesondere auch den fließenden
Übergang.
> Das 'B'> für Ball/Bulb ist ja auch von der Belichtungseinstellung entschwunden...
Und "T" auch. Solange es wenigstens noch die Möglichkeit gibt, nach
Wunsch lange zu belichten, ist mir die Bezeichnung nicht gar so wichtig;
Hauptsache. Ich finde die Einstellung.
Zaunwinker schrieb:> entsättigen" ist es nicht.
Wenn mann nicht weiß, was in diesem Metier "Sättigung" bedeutet, dann
nicht, wohl wahr. Und?
Wenn Du nicht weißt, was "Interschneiden" bedeutet, kannst Du mit
keinem Textprogramm oder gar Layouter vernünftig arbeiten. Der
Nürnberger Trichter ist zur Zeit nicht verfügbar. Also hör auf zu
jammern und lerne lieber, Deine Software zu benutzen wie ein
Erwachsener.
Hallo TO!
Hast du nicht mal eine Digiknipse oder Scanner gekauft?
Da ist oft brauchbare Soft beigelegt.
Kann auch älter sein.
Vor fast 20 Jahren war dem Diascanner Photoshop Elements 2.0 beigelegt.
Reicht vollkommen, geht auch unter W10 noch.
Auch mal bunte Computerzeitschriften mit CD durchforsten.
Foto Line wurde schon genannt.
Hallo
Manfred Malicious schrieb:> Kritischer als die Startzeit, finde ich dagegen die Einarbeitszeit, da> kann man schon mal locker ein Wochenende rechnen bis man das fachlatein> drauf hat ('Abwedeln', 'Entsättigen')
Das ist jetzt nicht böse gemeint und soll nicht überheblich klingen aber
um mal bei einen Vergleich zu bleiben, der vielleicht ein wenig hinkt:
"Mathematik ist schon ein geniales Werkzeug wenn man es beherrscht,
kritischer sieht es allerdings mit der jahrelangen Einarbeitungszeit und
den extremen Fachlatain aus"
Bildbearbeitung ist halt ein weiteres sehr tief gehendes Thema was
(leider?) auch heftig auf die Vergangenheit und Begrifflichkeiten daraus
aufbaut.
Wer diese noch kennt bzw. wenigsten die Denkweise dahinter beherrscht
hat natürlich seine Vorteile.
Ansonsten: Schaue dich tatsächlich bei den diversen "kleinen" Programmen
um die hier schon empfohlen wurden - allerdings bleiben dir auch all die
unglaublichen Möglichkeiten verborgen welche die Kaliber wie Gimp und
darüber zur Verfügung stellen - aber natürlich verringert sich die
"Gefahr" in einen weiteren schnell teuer und zeitintensiv werdenden aber
auch unglaublich faszinierenden Hobby ein zu steigen... Fotografie und
die Bildbearbeitung hat wenn mal einmal "drin steckt" sein
Suchtpotential ;-)
Thomas O. schrieb:> auf meinem Raspberry dauert es genau 5 Sekunden ohne das was vorgeladen> ist.
Unter Windows? ;-)
Dass es unter unixoiden Systemen flink lädt, wurde ja schon ein paarmal
bestätigt.
Es sollte ja tatsächlich mal ein Windows für den Raspberry Pi geben,
aber irgendwie isses wieder ruhig geworden darum …
Jörg W. schrieb:> Nano schrieb:>> das zusätzliche fettte Bibliotheken laden muss>> Weiß ja nicht, wie das unter Windows ist – unter unixoiden Systemen ist> das doch alles load-on-demand.
Unter Linux ist es folgendermaßen.
Verwendest du als Desktopenvironment Mate oder XFCE, dann sind die
Bibliotheken für Gimp schon im RAM. (Bei Gnome 3 bin ich mir gerade
nicht so sicher, ob Gimp schon auf GTK 3 umgestellt wurde)
Verwendest du KDE, muss die GTK Bibliothek nachgeladen werden.
Für Qt oder kdelibs Programme verhält es sich genau umgekehrt.
Und unter Windows ist weder Qt noch GTK heimisch. Da ist es die WinAPI
und MFC.
Früher, als noch Festplatten verbaut waren, merkte man das deutlich.
Wollte man schnelle Startzeiten, dann lohnte es sich darauf zu achten
und die Programme passend zu den Bibliotheken, die auch das Desktop
Environment verwendet, auszuwählen.
Heute mit SSD ist das nicht mehr so schlimm, aber der TS sagte auch
nicht, was er verbaut hat.
> Es ist also völlig egal, ob die> Bibliotheken "fett" sind
Es geht hier nicht um den Speicherbedarf, sondern um den Ladevorgang.
Bei Festplatten war das durchaus bemerkbar.
So ein Editor, der noch die WinAPI nutzte, war weitaus schneller bereit,
als ein Editor, der noch GTK laden musste.
Und unter Linux verhielt es sich ähnlich, wenn die Anwendung und das DE
unterschiedliche GUI Toolkits verwendete.
> Wie oben geschrieben: ich denke, dass das eher das Anfassen vieler> Dateien ist, bei dem Windows halt wirklich langsam ist.
Gimp braucht auch unter KDE zum Laden etwas länger.
Man merkt das nur nicht mehr so, da man ja üblicehrwise heute SSD für
Anwendungen verbaut hat.
> Was übrigens auch völlig gegen die These vom "bösen fetten> Linux-Toolkit" spricht: ich habe gerade mal spaßeshalber den> Windows-Build von gerbv getestet. gerbv basiert ja wie Gimp auch auf dem> Gtk, es schleppt auch (zumindest hier unter meinem FreeBSD) sackweise> andere shared libs mit rein:> ...>> Nichtsdestotrotz startet das auf Windows innerhalb von Millisekunden.
SSD sei Dank.
Mach den Test mit einer Festplatte noch einmal.
Noch etwas.
Die Ladezeit von Gimp war mir eigentlich immer egal, aber gerade bei den
Texteditoren und beim Dateimanager wollte ich immer eine nahezu
Instantverfügbarkeit des Editors bzw. Dateimanagers haben.
Damals bei Festplatten habe ich also gezielt den Editor oder
Dateimanager passend zum Desktop ausgewählt.
Heute ist es, wie bereits gesagt, nicht mehr so gravierend, die SSD hat
das weitgehen egalisiert.
Ob der Editor jetzt in 0,3 ms oder 0,9 ms aufpoppt ist mir relativ egal.
Aber damals waren es halt ein paar Sekunden.
Geany brauchte unter Windows einige Zeit, bis es endlich da war.
Der Crimson Editor (FreeWare) war weitaus schneller verfügbar, der
verwendete damals soweit ich weiß die WinAPI oder MFC.
Heute nutze ich ihn nicht mehr.
Nano schrieb:> Es geht hier nicht um den Speicherbedarf, sondern um den Ladevorgang.
Nochmal: das "Laden" einer Bibliothek (shared lib) lädt nicht etwa
sämtliche Daten aus dieser in den RAM. Es macht sie lediglich dem
Betriebssystem bekannt. Geladen wird (speicher-)seitenweise "on demand",
also immer nur dann, wenn etwas referenziert wird.
>> Nichtsdestotrotz startet das auf Windows innerhalb von Millisekunden.>> SSD sei Dank.
Ist irrelevant, denn es ging ja darum, ob Gtk daran schuld wäre, dass
Gimp so langsam im Starten ist (was ja offenbar auch bei einer SSD der
Fall ist unter Windows). Wenn es am Gtk läge, dann müsste der
Unterschied auch bei gerbv spürbar sein, denn auch dort wird (siehe
meine ldd-Ausgabe) einiges an shared libs geladen.
gerbv startet aber schnell. Das Problem mit Gimp muss also woanders
liegen als im verwendeten GUI-Toolkit. Vermutung habe ich genannt: Gimp
liest beim Start ein paar Tausend Dateien ein, und das ist etwas, bei
dem Windows erfahrungsgemäß *) langsam ist.
*) Erfahrung: Projekte mit ein paar hundert Quelldateien compilieren.
Das Compilieren selbst ist nahezu OS-unabhängig, denn es rechnet ja nur
auf den eingelesenen Daten herum. Trotzdem ist Windows bei derartigen
Projekten fast eine Größenordnung langsamer als unixoide Systeme auf
gleicher Hardware. Da ein Compiler außer dem Herumrechnen auf den Daten
und dem Ein- und Auslesen von Dateien nicht viel anstellt, bleibt als
Schlussfolgerung nur, dass die Dateiarbeit unter Windows aus irgendeinem
Grunde langsam ist.
Jörg W. schrieb:> Nano schrieb:>> Es geht hier nicht um den Speicherbedarf, sondern um den Ladevorgang.>> Nochmal: das "Laden" einer Bibliothek (shared lib) lädt nicht etwa> sämtliche Daten aus dieser in den RAM. Es macht sie lediglich dem> Betriebssystem bekannt. Geladen wird (speicher-)seitenweise "on demand",> also immer nur dann, wenn etwas referenziert wird.
Ja und trotzdem kostet es Zeit, bei Festplatten auch merkbar.
>>> Nichtsdestotrotz startet das auf Windows innerhalb von Millisekunden.>>>> SSD sei Dank.>> Ist irrelevant, denn es ging ja darum, ob Gtk daran schuld wäre, dass> Gimp so langsam im Starten ist (was ja offenbar auch bei einer SSD der> Fall ist unter Windows).
Es kommt auf die Schmerzgrenze an, mit SSD geht es schnell genug. Für
die meisten jedenfalls.
> gerbv startet aber schnell. Das Problem mit Gimp muss also woanders> liegen als im verwendeten GUI-Toolkit. Vermutung habe ich genannt: Gimp> liest beim Start ein paar Tausend Dateien ein, und das ist etwas, bei> dem Windows erfahrungsgemäß *) langsam ist.
Ich bestreite nicht, dass diese Möglichkeit auch besteht.
Aber Geany hat nicht viele Dateien und hat damals, als ich noch
Festplatten verwendete auch recht lange gedauert, verglichen mit
Editoren wie Notepad und Co.
>> *) Erfahrung: Projekte mit ein paar hundert Quelldateien compilieren.> Das Compilieren selbst ist nahezu OS-unabhängig, denn es rechnet ja nur> auf den eingelesenen Daten herum. Trotzdem ist Windows bei derartigen> Projekten fast eine Größenordnung langsamer als unixoide Systeme auf> gleicher Hardware. Da ein Compiler außer dem Herumrechnen auf den Daten> und dem Ein- und Auslesen von Dateien nicht viel anstellt, bleibt als> Schlussfolgerung nur, dass die Dateiarbeit unter Windows aus irgendeinem> Grunde langsam ist.
Es gibt auch noch die Prozessswitches. Compilieren heißt ja nicht nur,
dass nur ein Prozess gestartet wird, sondern das ist oft ein
Sammelsurium an Tools. Von Make, dem Compiler, bis hin zum Assembler und
sonstigen Scriptsprachen.
Zaunwinker schrieb:> Percy N. schrieb:>> Abwedeln kennt man aus dem>> Fotolabor, und Entsättigen isr eigentlich selbsterklärend.>> Das letzte mal im (Chemischen) Fotolabor ist mindestens drei Jahrzehnte> her, und nach Schwarz/weiss konvertieren" wäre selbsterklärend,
Unter "schwarz/weiß" wird in dem Bereich öfter mal wirklich nur schwarz
und weiß, also 1 Bit pro Pixel verstanden.
Übrigens kommt bei mir, wenn ich auf den Menüeintrag gehe, ein Tooltip,
in dem drin steht: "Farben in Graustufen umwandeln". Und wenn man
effizienter arbeiten will, sind kurze knackige Begriffe von Vorteil,
statt ein ganzer Roman als Menüeintrag, den man erstmal erfassen muss,
um z sehen, ob es der gewünschte ist. Und wenn man einmal gehört hat,
was Farbsättigung ist, dann ist auch vollkommen klar, was entsättigen
ist.
> "entsättigen" ist es nicht.
Doch, ist es.
Jörg W. schrieb:> Es sollte ja tatsächlich mal ein Windows für den Raspberry Pi geben,> aber irgendwie isses wieder ruhig geworden darum …
Gibt es - jetzt sogar mit GUI. Nur ist es wohl furchtbar langsam:
https://www.heise.de/tipps-tricks/Raspberry-Pi-Windows-10-installieren-so-klappt-s-4456283.html
Kris schrieb:> Paint.Net
Das ist ein Clon des PaintShop Pro, irgendwann aus dessen Version 4.
(PaintShopPro 4.12 gibt es als ewig laufende Demo für lau).
Und Paint.Net zeigt eindrücklich, warum DotNet Scheisse ist: riesig,
grottenlangsam, und die kleinen Änderungen am Userinterface gingen alle
nach hinten los. Wer also Paint.Net empfiehlt, sollte PaintShop Pro 4.12
installieren. Ist zwar 23 Jahre alt, aber immer noch besser. Meins geht
seit dem neuen Drucker sogar wieder beim Scannen, mit dem alten MP780
fand es seit Win7 den Scanner nicht mehr.
Nano schrieb:> Es gibt auch noch die Prozessswitches. Compilieren heißt ja nicht nur,> dass nur ein Prozess gestartet wird, sondern das ist oft ein> Sammelsurium an Tools.
Das ist richtig, Prozesse sind bei Windows recht teuer, bei Unixen
genauso billig wie Threads.
Naja, wenn das jemanden ernsthaft interessiert, müsste er halt das
Timing von Gimp unter Windows mal debuggen.
Hallo
wendelsberg schrieb im Beitrag #6434030:
> Ironiedetektor kaputt?
Neu hier im Forum?
Für sich isoliert betrachtet magst du recht haben und es handelt sich
nur um eine einigermaßen witzige "frotzelei" die Auge in Auge unter
Kumpels auch funktionieren mag und die wirklich nichts mit
Respektlosigkeit oder gar mobben zu tun hat.
Auch ist es oft schwierig Ironie schriftlich in wenigen Worten zwischen
Fremden darzustellen.
Aber:
Wenn du dich auch nur ein wenig um Forum umsiehst erkennt man sehr
schnell das es sich in den meisten Fällen eben nicht um Ironie oder
neckereien handelt, sondern um bloßstellen, mobben, gehässig sein,
überheblich sein, andere Herabwürdigen und in irgendeiner Art und weise
"schwächere" fertig machen.
Das geht so gar nicht und nicht darauf zu reagieren ist keine Lösung
selbst wenn dadurch einige Trolle gefüttert werden und diese dann ihr
Späßchen haben, aber genug einfach nur bösartige, miese Zeitgenossen
meinen so was ernst und diesen darf man einfach keine Bühne bieten.
Wer schweigt macht sich schon mitschuldig - so sehr mich selbst dieser
Anspruch oft selbst stört und ich oft genug einfach nur wegsehen will.
Schade das die Moderatoren was das angeht zum großen teil viel zu
großzügig sind...
DSLR Nutzer
Wilf schrieb:> Gimpf (sic!) braucht doch auch unter Linux eine halbe Ewigkeit für den> Startvorgang. Selbst mit SSD.
Also bei mir so 1-2 Sekunden unter KDE, wo's ja angeblich eh schon
langsamer ist. Das empfinde ich noch nicht als "halbe Ewigkeit".
Beim ersten Start nach der Installation hat es aber tatsächlich
geschlagene 20 Sekunden gebraucht.
Nano schrieb:> Es gibt auch noch die Prozessswitches. Compilieren heißt ja nicht nur,> dass nur ein Prozess gestartet wird, sondern das ist oft ein> Sammelsurium an Tools. Von Make, dem Compiler, bis hin zum Assembler und> sonstigen Scriptsprachen.
Jörg meint vermutlich immerzu nur den GCC und man weiß nicht, ob er
auch noch mit anderen Compilern eine Erfahrung hat.
Meine damalige Erfahrung mit yagarto war, daß diese GCC Variante unter
Windows arschlangsam war - im völligen Gegensatz zum Keil.
Wahrscheinlich liegt der Unterschied Windows<-->Linux an den Links bei
Linux: Bei der yagarto Windows-Distribution waren alle Teile (Compiler,
Assembler, Linker) mehrfach unter verschiedenen Namen vorhanden (alle
binär gleich). Bei Linux nehme ich an, daß alle Programme nur ein
einziges Mal vorhanden sind, dafür aber verschiedennamige Links an den
betreffenden Stellen stehen, die auf die selbe Datei zeigen. Tja - und
wenn dann diese Datei bereits (bzw. noch) in irgend einem OS-Cache
steht, dann ist sie auch schnell geladen. Bei yagarto wurde offenbar
alles separat geladen und das kostet natürlich Zeit. Ich frag mich
ohnehin, was da beim GCC getrieben wird - wozu braucht man mehrere
binärgleiche Programme mit verschiedenen Namen? Geht sowas nicht
sinnvoller zu machen?
Es kommt da noch eines dazu: bei Windows haben eben viele Leute einen
Virenscanner laufen und der kostet bei jedem Programm-Laden ebenso
einiges an Prozessorzeit. Das sieht bei Insel-PC's ohne Netzwerkanschluß
und ohne aktiv mitlaufendem Virenscanner ganz anders aus.
W.S.
Tim schrieb:> Gibt es ein empfehlenswertes Bildbearbeitungsprogramm "in der Mitte"> zwischen diesen beiden?> Mir geht es dabei in der Hauptsache um Kontrast- und> Helligkeitsänderungen.
Nun, erstens kommt es drauf an, was du unter der "Mitte" verstehst. Für
mich rangieren Programme wie 'Gimpf' und Inkscape am Rande der
Unbenutzbarkeit, während Irfan-View, MSPaint und viel weiter oben
Photoimpact sehr angenehm zu benutzen sind.
Ich hatte ja schon mal auf Photoimpact hingewiesen. Das ist zwar relativ
alt, ist aber immer noch eine sehr gute Bearbeitungssoftware - und man
kriegt es für wenig Geld. Ulead Photo Impact X3 bei Amazon für 15€,
selbst bei Saturn und Co ist es zu haben, bei Ebay ebenfalls.
Aber wenn du lediglich am Kontrast, Helligkeit, Gamma, Farbsättigung und
RGB separat einzustellen, Freistellen/Beschneiden, Anwendung von
diversen Adobe 8BF Filtern (so du hast) interessiert bist, dann wäre
Irfan genau das Richtige für dich.
W.S.
W.S. schrieb:> Wahrscheinlich liegt der Unterschied Windows<-->Linux an den Links bei> Linux: Bei der yagarto Windows-Distribution waren alle Teile (Compiler,> Assembler, Linker) mehrfach unter verschiedenen Namen vorhanden (alle> binär gleich).
Der Compiler hat schon eine exakte Idee, welches Tool er jeweils für die
Aufgabe lädt. Da wird dann genau ein Assembler immer wieder geladen
und genau ein cc1 (Compiler + Präprozessor).
Daran liegt es nicht.
Auch IAR habe ich unter Windows nicht sonderlich schnell in Erinnerung.
Wenn Keil da schneller ist, könnte es natürlich daran liegen, dass sie
den Compiler anders organisieren und weniger Prozesse starten, weil mehr
innerhalb einunddesselben Binaries gemacht wird. Dass Prozesse unter
Windows schwergewichtig sind, hatten wir ja schon.
Aber: wir sind hier im Thread bei Gimp, dort gibt es nur einen Prozess.
Das ist also nicht das Problem.
> Es kommt da noch eines dazu: bei Windows haben eben viele Leute einen> Virenscanner laufen und der kostet bei jedem Programm-Laden ebenso> einiges an Prozessorzeit.
Je nach Virenscanner möglicherweise auch noch bei jeder Datei. Das
könnte dann auch für Gimp wieder ein Thema sein …
Christobal M. schrieb:> Gimpf lädt bei mir in unter 2 sec - bei geleertem FS Cache.
Unter Linux (XFCE4)
Ryzen 1600X, 48G RAM (FS Cache leer), 1TB MLC m.2 SSD.
Jörg W. schrieb:> Unter Windows? ;-)>> Dass es unter unixoiden Systemen flink lädt, wurde ja schon ein paarmal> bestätigt.
Unter Windows 6 sec.
Ryzen 3600, 16GB RAM, 2TB SATA SSD
ich wollte nur sagen das es an Windows liegen muss. Da ein RPi nicht
gerade die potenteste Hardware ist und das ganze von einer SD-Karte
geladen wird, also weit weg von der Leistung einer SSD.
Prometheus schrieb:> Ich wundere mich zu Hause immer wie schnell das geladen ist, ja das> dauert unter Windows durchaus 10s und länger.
Unfug.. mein uralt Gimp (2.2?) startet in unter 3sek auf meinem winXP
Knecht.
(nutz ich nicht wirklich, mag ich nicht wirklich hab ich deswegen auch
nicht in neuer oder auf 'neuerem' Rechner)
Aber wenn man nur begrenzt viele Funktionen braucht, braucht man auch
nicht die neueste version gelle?
Und wenn man sich die Win10 kagge ans Bein bindet, dann naja... hat man
eh schon verloren leider
'sid
sid schrieb:> Unfug.. mein uralt Gimp (2.2?) startet in unter 3sek auf meinem winXP> Knecht.
Nicht unbedingt Unfug, manche Programme brauchen beim Start ewig um die
installierten 1000den Fonts einzusammeln, manche laden Plugins bis zum
Abwinken. Wenn es bei DIR nicht so ist, heisst das noch lange nicht, das
Andere Unfug erzählen. Es liegt nur an deiner mangelnden Erfahrung dass
du so was noch nicht kennst.
MaWin schrieb:> Nicht unbedingt Unfug, manche Programme brauchen beim Start ewig um die> installierten 1000den Fonts einzusammeln, manche laden Plugins bis zum> Abwinken. Wenn es bei DIR nicht so ist, heisst das noch lange nicht, das> Andere Unfug erzählen. Es liegt nur an deiner mangelnden Erfahrung dass> du so was noch nicht kennst.
Falsch, es liegt an der mangelnden Erfahrung seine Programme ordentlich
einzurichten der Anderen.
Ich habe auf meiner xp Büchse insgesamt in etwa 30000 Schriftarten.
Nur eben nicht alle im Windoof FONT-Verzeichnisss (ich müsste ja
bescheuert sein!)
Dafür hab ich ein Fontmanager, der mir die Auslagerungsordner verwaltet
und Fonts zur Laufzeit nachladen kann wenn ich sie brauche (und wieder
entfernt wenn ich sie nichtmehr brauche)
Ich weiss auch was Plugins sind, davon hab ich auch einige ausprobiert
in den Jahren seit Xp das letzte Mal neu installiert wurde (2004) ;
drei vier selbst geschrieben und ich glaub noch ein gutes Dutzend
irgendwo auf der Festplatte
Nur eben auch hier: die Unbenutzten sind immer ausgelagert und werden
nur wenn notwendig wieder geladen.
das erfordert dann ggf einen GIMP neustart, jau, der dauert dann
vielleicht ne zehntel Sekunde länger, stimmt auch
aber zehn Sekunden fänd ich schon nervig.
Ich benutze Gimp nicht wirklich, mein 'noch älteres' Photoshop ist mir
schlicht lieber auf dieser Uralt-büchse (beide laden in etwa gleich
schnell)
Ich müsste also mal gucken ob ich Gimp überhaupt so langsam bekomme ohne
mir dabei die Finger zu verrenken.
Das Problem ist, dass manche sich Kokolores aufhalsen wollen den man nie
braucht,
und sich dann gleichzeitig wundern warum alles so unfassbar zäh und
langsam lädt (und läuft).
Schmeisst man den Kokolores weg (oder lagert ihn sinnvoll aus) und
behält nur was man grade braucht,
dann läuft auch in 2020 ein WinXP auf 2Ghz Prozessor mit 2GB Ram noch
ausreichend schnell für das tägliche (Privat-)Leben.
(Und nein, das ist nicht mein einziger Computer zum Glück..
denn wenn ich irgendwo fester drauf hauen muss, dann könnte die Büchse
das in der Tat nichtmehr adäquat)
Für 'banale' Bildbearbeitung um die es hier zu gehen scheint allerdings,
ist die Uraltkiste mehr als genug!
Da ist mein abgespecktes GIMP mehr als Genug (nur mir eben unbequem)
und es braucht dann eben keine 10sekunden bis es mal nutzbar geladen
ist.
Die Aussage dass es an Gimp liegt, dass es zehn Sekunden braucht ist
also defacto UNFUG!
(muss es ja nicht brauchen offensichtlich)
Und wenn es hier dem Thema nach um Minimalismus geht,
dann frage ich mich ob der Fragende interesse an tausenden Schriftarten
und hunderten Plugins überhaupt haben kann...
'sid
Jörg W. schrieb:> Der Compiler hat schon eine exakte Idee, welches Tool er jeweils für die> Aufgabe lädt.
Dann erkläre mir mal, zu welchem Zwecke alle Programme (Compiler,
Assembler, Linker..) dort mehrfach vorkommen. Wohlgemerkt: bei binärer
Gleichheit.
W.S.
W.S. schrieb:> Dann erkläre mir mal, zu welchem Zwecke alle Programme (Compiler,> Assembler, Linker..) dort mehrfach vorkommen.
Wie du schon festgestellt hast: weil's unter Windows keine Links gibt.
Normalerweise wird das einfach nur auf diese Weise unter verschiedenen
Namen installiert, und man kann dann auch mehrere Versionen parallel
halten.
Die vom Compiler-Frontend aufgerufenen Backend-Programme gibt's übrigens
sowieso jeweils nur einmal; die verschiedenen Versionenn werden dort
über Verzeichnisnamen auseinander gehalten.
Die Ladezeit ist doch nicht wirklich das Problem bei Gimp. Das
wirkliche, fundamentale und ultimative Problem bei Gimp ist, dass man
keinen vernünftigen Normpfeil mit 15° Pfeilspitze kann. Gimp kann
eigentlich alles, was man wiklich im täglichen leben braucht, und noch
viel mehr. Aber einen Versuchsaufbau zu zeigen und einige interessante
Sachen mit Pfeilen und Beschriftung versehen, da hat leider keiner dran
gedacht. Deshalb ist Gimp bei mir bis auf weiteres raus.
DoS schrieb:> Die Ladezeit ist doch nicht wirklich das Problem bei Gimp. Das> wirkliche, fundamentale und ultimative Problem bei Gimp ist, dass man> keinen vernünftigen Normpfeil mit 15° Pfeilspitze kann.
Man kann. Braucht aber ein klein wenig Eigeninitiative.
Ich habe jetzt mal GIMP 8.4 auf einem älteren Testrechner unter VISTA
installiert.
Der Erststart dauerte etwas, aber sonst geht es doch.
Nicht der Rede wert.
Aber für gelegentliche Bildkorrekturen, wie es der TO möchte, ist es zu
monsterhaft.
Es dauert, bis man die Menues und Tafeln beherrscht.
Und die fliegenden Fenster sind ja immer noch da.
Das Konzept ist nicht mein Ding.
DoS schrieb:> Die Ladezeit ist doch nicht wirklich das Problem bei Gimp. Das> wirkliche, fundamentale und ultimative Problem bei Gimp ist, dass man> keinen vernünftigen Normpfeil mit 15° Pfeilspitze kann. Gimp kann> eigentlich alles, was man wiklich im täglichen leben braucht, und noch> viel mehr. Aber einen Versuchsaufbau zu zeigen und einige interessante> Sachen mit Pfeilen und Beschriftung versehen, da hat leider keiner dran> gedacht. Deshalb ist Gimp bei mir bis auf weiteres raus.
Wozu sollte ein Bildbearbeitungsprogramm sowas können?
Dafür gibt es andere, die das besser machen.
Das sind vektororientierte Programme.
Z.Bsp. Libre Office Draw oder Impress.
michael_ schrieb:> Aber für gelegentliche Bildkorrekturen, wie es der TO möchte, ist es zu> monsterhaft.> Es dauert, bis man die Menues und Tafeln beherrscht.
Muss man ja auch nicht.
Es reicht, ein Bild zu laden, die paar Änderungen vorzunehmen, und das
Bild zu exportieren.
All die Bells&Whistles kann man in Ruhe lassen.
Tim schrieb:> Mir geht es dabei in der Hauptsache um Kontrast- und> Helligkeitsänderungen.
Einfach die Windows-eigene "Fotos"-App nehmen, die kann das u.a.
Jörg W. schrieb:> Es würde mich ehrlich wundern, wenn das unter Windows heutzutage anders> wäre.
Ist es nicht. Und nicht erst seit heute, sondern schon seit seligen
Windows-NT-Zeiten. Das war also lange vor dem ersten einigermaßen
brauchbaren Linux...
> Wie oben geschrieben: ich denke, dass das eher das Anfassen vieler> Dateien ist, bei dem Windows halt wirklich langsam ist.
Nein, der Gegenbeweis wurde doch bereits angetreten: Wenn Office die
Fonts enumeriert, muß es exakt so viele Dateien anfassen wie auch Linux.
Nämlich schlicht die im System registrierten Font-Dateien. Daß man das
schnell und effizient tun kann, beweisen z.B. MS-Office (aber auch
Photoshop, CorelDraw und viele andere Programme).
Gimp kann es unter Windows nicht, unter Linux kann es das. Was ist die
logische Schlußfolgerung?
Deine ist: Windows ist Scheiße. Meine ist: Gimp ist Scheiße (zumindest
der Windows-spezifische Teil).
Welcher Schluß ist logischer? Möge die Nachwelt darüber urteilen...
c-hater schrieb:> Ist es nicht. Und nicht erst seit heute, sondern schon seit seligen> Windows-NT-Zeiten.
Hatte ich erwartet.
> Das war also lange vor dem ersten einigermaßen> brauchbaren Linux...
Für dich ist doch Linux auch heute nicht brauchbar, für andere wiederum
waren Unixe schon weit vor WinNT brauchbar … (und hatten bereits demand
paging).
> Nein, der Gegenbeweis wurde doch bereits angetreten: Wenn Office die> Fonts enumeriert, muß es exakt so viele Dateien anfassen wie auch Linux.
Erstens ist das keineswegs sicher, zweitens wurde eingangs schon
geschrieben, dass er die Fonts sowieso nur beim ersten Start einliest
(und dann die Information cachet). Aber nichtsdestotrotz zähle ich
irgendwas um 2500 zu öffnende Dateien auch bei einem normalen Start von
Gimp. Du kannst ja im Gegenzug gern mal die zählen, die Office öffnet.
(Ich muss mir nicht antun noch rauszufinden, wie man das unter Windows
zählt. Mir reicht es, wenn ich das unter Linux und FreeBSD kann.)
Davon abgesehen, aus meiner Sicht ist auch Office schnarchlangsam beim
Starten – egal ob MS Office oder LibreOffice. Ist also eher ein
Nicht-Argument.
Percy N. schrieb:>> Es dauert, bis man die Menues und Tafeln beherrscht.>> Muss man ja auch nicht.> Es reicht, ein Bild zu laden, die paar Änderungen vorzunehmen, und das> Bild zu exportieren.
Vielleicht wenn man eingearbeitet ist.
Bild laden? Das findet schon mal nicht dort, wo es alle andere Programme
anbieten.
Gleiches auch für den Scanner-Import.
bluppdidupp schrieb:> Einfach die Windows-eigene "Fotos"-App nehmen, die kann das u.a.
Es dauert ewig, bis ein Bild geladen ist.
Und die Funktionen sind mehr als spartanisch.
michael_ schrieb:> Bild laden? Das findet schon mal nicht dort, wo es alle andere Programme> anbieten.
Hmm, also hier ist es unter File -> Open, wo sollte es sonst sein?
michael_ schrieb:> Vielleicht wenn man eingearbeitet ist.
Welche zusätzlichen Arbeittsschritte muss man denn bis dahin
beherrschen, Deiner Meinung nach?
Stell Dir vor: Audacity funktioniert auch etwas anders als der
Mediaplayer ...
michael_ schrieb:> "Einfach, primitiv und doch geschmacklos."
Du erinnerst mich gerade an Walther Matthau in "Ein seltsames Paar": das
Tekefon klingelt, er nimmt ab und neldet sich "Hallo, hier geschieden,
pleite und schlampig?"
Jörg W. schrieb:> Für dich ist doch Linux auch heute nicht brauchbar
Wie kommst du auf diese Idee? Ich benutze Linux vollkommen regulär.
Klar: seltener als Windows, was aber eben daran liegt, dass es viele
Anwendungen, die ich regelmäßig zu benutzen gezwungen bin, eben nur für
Windows gibt.
Die normative Kraft des Faktischen halt...
> für andere wiederum> waren Unixe schon weit vor WinNT brauchbar
Wir reden hier schon von Linux? Dass es schon Unix vor Linx gab, hat
hier niemand bestritten. Der Punkt ist halt: praktisch nix davon hat bis
heute überlebt (lebensverlängernde Maßnahmen für sterbende Altlasten mal
ausgenommen).
Die Ausnahme von dieser Regel sind halt Linux und die diversen
BSD-Derivate. Sooo gut kann das olle Unix-Zeuchs also auch wieder nicht
gewesen sein, was es vor NT gab, sonst hätte es überlebt...
Auch hier gelten die Gesetze der Evolution: was sich nicht verändert und
der Umwelt anpasst, das stirbt. So gut es zu seiner besten Zeit auch mal
angepasst gewesen sein mag...
> Erstens ist das keineswegs sicher
Natürlich ist das sicher. Es sei denn, man benutzt noch viele Dateien
mehr. Da alle Information über einen Font aber in der Font-Datei
gespeichert sind, ist die Benutzung weiterer Dateien in diesem
Zusammenhang schlicht Bullshit. Maximal wäre eine zusätzliche Datei
akzeptabel: eine Cache-DB.
> zweitens wurde eingangs schon> geschrieben, dass er die Fonts sowieso nur beim ersten Start einliest> (und dann die Information cachet).
Das tut er offensichtlich eben nicht. Aktuell dauert allein der Teil mit
den Fonts beim Start von Gimp auf meinem Rechner satte 45 Sekunden. Und
nicht nur beim ersten Start, sondern auch bei jedem folgenden.
Auch witzig: nicht nur der Start dauert eine kleine Ewigkeit, auch das
Beenden. Ca. 10 Sekunden, bis der Prozess terminiert, nachdem man im
Hauptfenster das Close-Icon angklickt hat. In der Zwischenzeit bleiben
offene Tool-Windows sichtbar, sind aber natürlich nicht mehr reaktiv...
> Aber nichtsdestotrotz zähle ich> irgendwas um 2500 zu öffnende Dateien auch bei einem normalen Start von> Gimp. Du kannst ja im Gegenzug gern mal die zählen, die Office öffnet.
Viel mehr. Witzigerweise sind aber nur ganz wenige Font-Dateien dabei,
im Extremfall (Locale ist Latin1-kompatibel und der eingestellte
Systemfont ist TrueType und es gibt keine getrennten Varianten für
bold/narrow/italic oder kleine Größen) sogar nur eine einzige.
Es schafft es aber trotzdem, über alle verfügbaren Fonts vollständig im
Bilde zu sein. Genau das ist der Trick: es baut keinen eigenen Cache,
sondern nutzt den des OS, bei dem die Fonts ja bereits alle registriert
wurden (was die sinnvolle Kategorisierung ihrer Eigenschaften
einschließt). So ist es richtig.
> (Ich muss mir nicht antun noch rauszufinden, wie man das unter Windows> zählt. Mir reicht es, wenn ich das unter Linux und FreeBSD kann.)
Da sieht man, was Schmalspuridioten und Fanboys ausmacht (im Vergleich
zu Pragmatikern wie mir). Ich weiß das für Windows UND für Linux UND
für BSD...
> Davon abgesehen, aus meiner Sicht ist auch Office schnarchlangsam beim> Starten
Also nehmen wir mal Word (konkret das aus Office 2019): startet in knapp
vier Sekunden. Zeit vom Anklicken des Icon bis zur Reaktivität des
Hauptfensters. Selber Rechner, selbe Zahl Fonts wie bei den o.g. Zeiten
für Gimp...
W.S. schrieb:> Ich frag mich> ohnehin, was da beim GCC getrieben wird - wozu braucht man mehrere> binärgleiche Programme mit verschiedenen Namen? Geht sowas nicht> sinnvoller zu machen?
Wieso? Unter Linux ist es nichts ungewöhnliches, dass ein Programm per
Symlinks unter mehreren Namen vorhanden ist und seine Funktionalität
danach anpasst, unter welchem davon es gestartet wird. Bei Busybox
werden so im Prinzip alle gängigen Shelltools über ein einzelnes
Executable abgebildet, das damit auch nur einmal in den Speicher geladen
werden muss. Und bei anderen Programmen wird es gerne gemacht, wenn es
unterschiedliche Varianten des Programms früher gab und das neue die
alte Funktionalität aus Kompatibilitätsgründen nachbildet, aber unter
seinem neuen Namen dann mit neuer Funktionalität läuft.
Warum soll man da was "sinnvoller" machen? Nur weil die Unterstützung
von Windows für Symlinks noch immer irgendwo zwischen jämmerlich und
nicht vorhanden liegt, obwohl das schon seit Windows NT im Dateisystem
eigentlich vorgesehen ist und auch sogar stellenweise genutzt wird?
W.S. schrieb:> Nun, erstens kommt es drauf an, was du unter der "Mitte" verstehst. Für> mich rangieren Programme wie 'Gimpf' und Inkscape am Rande der> Unbenutzbarkeit, während Irfan-View, MSPaint und viel weiter oben> Photoimpact sehr angenehm zu benutzen sind.
Paint? Das ist doch fürchterlich. Kann praktisch gar nix, und das, was
es kann, ist eher merkwürdig umgesetzt. Zum Beispiel: Man zieht einen
Selektionsrahmen um einen Teil des Bildes. Dann merkt man, dass eine
Ecke nicht passt und man sie nochmal verschieben musst. Warum zum Henker
meint Paint dann, den Teil des Bildes in der Selektion nun mit dieser
skalieren zu müssen?
Percy N. schrieb:> michael_ schrieb:>> Aber für gelegentliche Bildkorrekturen, wie es der TO möchte, ist es zu>> monsterhaft.>> Es dauert, bis man die Menues und Tafeln beherrscht.>> Muss man ja auch nicht.> Es reicht, ein Bild zu laden, die paar Änderungen vorzunehmen, und das> Bild zu exportieren.>> All die Bells&Whistles kann man in Ruhe lassen.
Das denke ich mir auch immer, aber ein Großteil der Menschen will
Software, die nur möglichst genau das kann, was die machen wollen und
nicht mehr. Alles andere verwirrt sie zu sehr, und sie können dann
nichts damit anfangen. Habe ich nie verstanden, aber so ist es.
c-hater schrieb:> Gimp kann es unter Windows nicht, unter Linux kann es das. Was ist die> logische Schlußfolgerung?
Dass man unter Windows halt zusätzliche Tricks braucht, um es auch dort
flott zu bekommen. Das lahme Dateihandling war ja auch ein wesentlicher
Grund, weshalb damals die Registry eingeführt wurde. Man hat das Problem
halt nicht behoben, sondern umgangen. Und bei gimp müsste man vermutlich
auch zusätzlichen Aufwand treiben, um solche Einschränkungen von Windows
zu umgehen. Das wurde wohl nicht gemacht.
Rolf M. schrieb:> Alles andere verwirrt sie zu sehr, und sie> können dann nichts damit anfangen. Habe ich> nie verstanden, aber so ist es.
Verstehe ich nicht.
Auf der Kommandozeile gilt "one task -- one tool",
aber bei Programmen mit GUI plötzlich nicht mehr?
michael_ schrieb:> DoS schrieb:> Die Ladezeit ist doch nicht wirklich das Problem bei Gimp. Das> wirkliche, fundamentale und ultimative Problem bei Gimp ist, dass man> keinen vernünftigen Normpfeil mit 15° Pfeilspitze kann. Gimp kann> eigentlich alles, was man wiklich im täglichen leben braucht, und noch> viel mehr. Aber einen Versuchsaufbau zu zeigen und einige interessante> Sachen mit Pfeilen und Beschriftung versehen, da hat leider keiner dran> gedacht. Deshalb ist Gimp bei mir bis auf weiteres raus.>> Wozu sollte ein Bildbearbeitungsprogramm sowas können?> Dafür gibt es andere, die das besser machen.> Das sind vektororientierte Programme.>> Z.Bsp. Libre Office Draw oder Impress.
Na ja, wenn ich Fotos von Experimenten mache, sind die häufig schief,
der Weißabgleich ist fehlerhaft und die Gradiation ist nicht optimal.
Wenn ich mir die Arbeit mache, einen Herichtnzu schreiben, dann soll der
auch gute, informative Bilder enthalten. Derzeit nehme ich dafür immer
noch Ulead Photoimpact 12 (kein Witz). Das macht aber mit dem
Fortschreiten von Windows immer größere Probleme.
Egon D. schrieb:> Rolf M. schrieb:>>> Alles andere verwirrt sie zu sehr, und sie>> können dann nichts damit anfangen. Habe ich>> nie verstanden, aber so ist es.>> Verstehe ich nicht.>> Auf der Kommandozeile gilt "one task -- one tool",> aber bei Programmen mit GUI plötzlich nicht mehr?
Möchtest du, wenn du ein Bild skalieren und etwas nachschärfen willst,
dieses dazu erst in einem Tool öffnen, skalieren, speichern, im zweiten
Tool öffnen, schärfen, wieder speichern, statt ein Tool, das beides
macht?
Man muss auch beachten, dass man einzelne GUI-Programme nicht so einfach
und komfortabel miteinander kombinieren kann wie Kommandozeilentools, a
la
Tim schrieb:> zwischen Paint und Gimpf für Win10?
Wenn schon verballhornen, dann weiß ich nicht ob in einem Gimp zu
stecken... https://www.google.com/search?q=gimp+anzug ... und PAIN(t)
nicht im Endeffekt dasselbe ist. Jedenfalls nichts für mich. SCNR
c-hater schrieb:> Also nehmen wir mal Word (konkret das aus Office 2019): startet in knapp> vier Sekunden.
Eben, schnarchlangsam.
Auf der gleichen Hardware startet Gimp (unter Linux) in 0,5 Sekunden.
Wie viele Dateien so ein Word öffnet, kannst du mir aber offenbar auch
nicht schreiben …
Rolf M. schrieb:> Das denke ich mir auch immer, aber ein Großteil der Menschen will> Software, die nur möglichst genau das kann, was die machen wollen und> nicht mehr. Alles andere verwirrt sie zu sehr, und sie können dann> nichts damit anfangen. Habe ich nie verstanden, aber so ist es.
Vor ~20 Jahren gab konnte man bei BMW aufpreisfrei(!) Fahrzeuge mit
Nichtraucherausstattung ordern; die hatten weder Zigarrenanzünder noch
Aschenbecher.
Ob viel davon verkauft wurde, weiß ich nicht; eine Freundin von mir
benutzte danaks in ihrem Auto den Aschenbecher für Lakritzen, andere
parkten dort ihre Parkgroschen.
Egon D. schrieb:> Verstehe ich nicht.> Auf der Kommandozeile gilt "one task -- one tool", aber bei Programmen> mit GUI plötzlich nicht mehr?
Was erzählst Du da?
Das galt noch nicht einmal für die Spezialisten, die meinten, sie
müssten ihre Korrespondenz mit DEBUG erledigen, weil ED schon zu mächtig
war ...
Richtig ist allerdings, dass WordStar unter CP/M keine Fußnoten konnte;
mit einem Zusatztool ging es, war aber schlimmer als von hinten durch
die Brust ins Auge. Eine einzige Qual ...
Die Integration von MailMerge hingegen war deutlich besser grlungen.
Heute hat man den Vorteil, dass der ganze Quatsch gleichzeitig in den
Speicher passt.
michael_ schrieb:> Es dauert ewig, bis ein Bild geladen ist.> Und die Funktionen sind mehr als spartanisch.
Dann eben doch Irfanview.
Schnell, und kann (fast) alles, was ich für viele Aktionen benötige,
das ganze auch im Batch-Betrieb.
Percy N. schrieb:> Rolf M. schrieb:>> Das denke ich mir auch immer, aber ein Großteil der Menschen will>> Software, die nur möglichst genau das kann, was die machen wollen und>> nicht mehr. Alles andere verwirrt sie zu sehr, und sie können dann>> nichts damit anfangen. Habe ich nie verstanden, aber so ist es.>> Vor ~20 Jahren gab konnte man bei BMW aufpreisfrei(!) Fahrzeuge mit> Nichtraucherausstattung ordern; die hatten weder Zigarrenanzünder noch> Aschenbecher.
Wenn dafür dann irgendein anderes Fach oder ein Cupholder oder so was
drin ist, ist das ja ok. Ich freue mich, in meinem Auto keinen
Aschenbecher, aber dafür eine induktive Ladefläche fürs Handy zu haben.
Ich kann mich aber auch noch an die Zeiten erinnern, in denen gegen
Aufpreis die Typenbezeichnung auf dem Heckdeckel weggelassen wurde.
Aber bei der Konfiguration von Fahrzeug-Ausstattung fehlt mir oft
sowieso das Verständnis. Da gibt's dann so Merkwürdigkeiten, dass man
z.B. die größte Ausstattung beim Radio nur in Kombination mit bestimmten
Dachhimmel-Farben bekommt. Und früher waren die Außenspiegelgehäuse in
Grundausstattung schwarz. Wollte man sie in Wagenfarbe, hat das extra
gekostet. Heute ist es umgekehrt: Sie kommen serienmäßig in Wagenfarbe,
und in schwarz kosten sie Aufpreis.
Teo D. schrieb:> Björn schrieb:>> Im Bild>> malen, kopierstempeln, einzelne Stellen abwedeln etc. geht damit aber>> nicht.>> Klar kann es das, drück mal F12! Recht rudimentär aber es geht schon> was.
Ich geh kapott ;-) Das war mir neu, vielen Dank!
Jörg W. schrieb:> Wie du schon festgestellt hast: weil's unter Windows keine Links gibt.> Normalerweise wird das einfach nur auf diese Weise unter verschiedenen> Namen installiert, und man kann dann auch mehrere Versionen parallel> halten.
Tja, genau so hatte ich mir das auch gedacht - und damit ist klar, daß
das Laden von zwar inhaltlich gleichen, aber dateimäßig mehreren
Programmen eben auch mehr Zeit braucht.
W.S.
DoS schrieb:> Die Ladezeit ist doch nicht wirklich das Problem bei Gimp. Das> wirkliche, fundamentale und ultimative Problem bei Gimp ist, dass man> keinen vernünftigen Normpfeil mit 15° Pfeilspitze kann. Gimp kann> eigentlich alles, was man wiklich im täglichen leben braucht, und noch> viel mehr.
Hä?
Also ich brauche für... nein, nicht ALLES, jedoch für sehr vieles im
täglichen Leben ein 2D CAD, mit dem ich konstruieren kann. Das kann dann
auch normgerechte Bemaßung (je nachdem, was man haben will: Metallbau
ist anders als Bauwesen usw.).
Irgendwelche Grafik- Bild- oder Malprogramme können eben nicht zum
Konstruieren benutzt werden und sin dafür auch nicht vorgesehen. Also
sollte man lieber das zum jeweiligen Zweck gedachte Programm nehmen.
Auch hier gilt, daß die eierlegenden Wollmilchsauen zwar von allem ein
wenig, aber nichts richtig können.
W.S.
W.S. schrieb:> Also sollte man lieber das zum jeweiligen Zweck gedachte Programm> nehmen.
Es haben auch schon Leute Leiterplatten mit Corel Draw oder so
entworfen. Der Autorouter von OpenOffice Draw gilt allerdings als etwas
träge ...
Rolf M. schrieb:> Wieso? Unter Linux ist es nichts ungewöhnliches, dass ein Programm per> Symlinks unter mehreren Namen vorhanden ist...
Ich schrieb über yagarto und zwar in der Windows-Ausführung. Hast du das
denn nicht gelesen???
Rolf M. schrieb:> Paint? Das ist doch fürchterlich. Kann praktisch gar nix, und das, was> es kann, ist eher merkwürdig umgesetzt.
Sehe ich nicht so. Es ist ein eher kleines Programm, aber es ist nicht
fürchterlich.
W.S.
W.S. schrieb:> und damit ist klar, daß das Laden von zwar inhaltlich gleichen, aber> dateimäßig mehreren Programmen eben auch mehr Zeit braucht.
Nur dass niemand von sich aus diese Dateien jemals anfasst.
Wenn also was dadurch länger dauert, dann ist es das Installieren des
Compilers.
W.S. schrieb:> Tja, genau so hatte ich mir das auch gedacht - und> damit ist klar, daß das Laden von zwar inhaltlich> gleichen, aber dateimäßig mehreren Programmen eben> auch mehr Zeit braucht.
Unter Windows vielleicht.
Unter Linux ist es ja so, dass die Datei zwar mehrere
unterschiedliche Verzeichniseinträge (=Namen) hat, aber
letztlich nur einmal auf dem Medium gespeichert ist und
nur einen INode belegt. Ich würde daher erwarten, dass
die Cache-Verwaltung den identischen INode erkennt und
den Dateiinhalt aus dem Cache verwendet.
Rolf M. schrieb:> Möchtest du, wenn du ein Bild skalieren und etwas> nachschärfen willst, dieses dazu erst in einem Tool> öffnen, skalieren, speichern, im zweiten Tool öffnen,> schärfen, wieder speichern, statt ein Tool, das beides> macht?
Nein, natürlich nicht. Das wäre dann doch etwas zuviel
des Guten...
> Man muss auch beachten, dass man einzelne GUI-Programme> nicht so einfach und komfortabel miteinander kombinieren> kann wie Kommandozeilentools, [...]
Wieso eigentlich nicht?
Wenn die "Geschäftslogik" -- z.B. die Aufgabe, Webseiten
zu rendern -- in einem Serverprozess steckt, sollte es
doch kein Problem sein, diesen Server mit einem Clienten
zu kontaktieren, der z.B. die Bookmark-Verwaltung macht.
Gewinn für den Anwender: Nicht nur die Bookmark-Sammlung
ist dann browserunabhängig -- auch die Bookmark-Verwaltung
ist es.
Egon D. schrieb:> Unter Windows vielleicht.
Jajaja, bei der "yagarto"-Distribution vor einigen Jahren, um das mal
exakt zu formulieren.
Und: eben dieses wurde bereits ausführlich hier abgehandelt. Ist also
erledigt.
Rolf M. schrieb:> Möchtest du, wenn du ein Bild skalieren und etwas nachschärfen willst,> dieses dazu erst in einem Tool öffnen, skalieren, speichern, im zweiten> Tool öffnen,
Du widersprichst dir selber: Wenn man EIN BILD skalieren, nachschärfen
etc. möchte, dann macht man das so. Und gleich anschließend meinst du
ein zweites Bild nachschieben zu müssen. Vielleicht meinst du "wenn man
VIELE Bilder skalieren,....".
Gerade bei Bildern ist jedoch jegliche Batch-Abarbeitung eine extrem
fischige Sache. Da kommt es auf das Auge des grafischen Fachmannes an,
ob und in welchem Grade ein Bild überhaupt nachgeschärft oder mehr oder
weniger gesättigt oder sonstwie bearbeitet werden muß, oder inwieweit es
beschnitten werden soll.
So etwas kann KEINE automatisierte Abarbeitung leisten, dazu ist der
Mensch erforderlich. Allerdings kein Administrator, der versteht von
Grafik ohnehin rein garnichts, sondern ein Grafiker - eben einer, der
eher auf der künstlerischen Seite ist.
W.S.
Jörg W. schrieb:> Nur dass niemand von sich aus diese Dateien jemals anfasst.
Aber offenbar sind eben diese Dateien bei Windows (und eben die Links
bei Linux) für das Funktionieren der ganzen Toolchain notwendig.
Und nein, so ganz eigentlich ist das mit dem GCC kein Thema, worüber ich
mir jetzt den Kopf zerbrechen müßte.
Allenfalls bleibt hier die Frage, ob dem TO außer MSPaint und 'Gimpf'
überhaupt noch irgend etwas bekannt sein könnte. Hier dediziert auf
diesem Gimpff und seinen Ladezeiten noch weiter herumzureiten, wird so
langsam uninteressant.
Was bleibt, ist eine Vielzahl von Windows-Programmen, mit denen man
Bildbearbeitung betreiben kann. Der TO hätte einfach bloß mal ein wenig
danach suchen müssen (sofern er kein Troll ist).
Und das Suchen zur rechten Zeit hat seine Meriten. Ich hatte z.B. das
komplette Softmaker-Office bei Pearl für stolze 5€ gekauft - und das ist
ein Stück handlicher als LibreOffice, kann aber sowohl mit Libre als
auch mit MS-Office die Dokumente austauschen (und das deutlich besser
als direkt MS<-->Libre). Geht also, man muß eben bloß mal die Nase aus
der Furche erheben und schauen, was es gibt - gilt auch für Gimpf-Leute.
W.S.
Egon D. schrieb:> Rolf M. schrieb:>>> Möchtest du, wenn du ein Bild skalieren und etwas>> nachschärfen willst, dieses dazu erst in einem Tool>> öffnen, skalieren, speichern, im zweiten Tool öffnen,>> schärfen, wieder speichern, statt ein Tool, das beides>> macht?>> Nein, natürlich nicht. Das wäre dann doch etwas zuviel> des Guten...>>> Man muss auch beachten, dass man einzelne GUI-Programme>> nicht so einfach und komfortabel miteinander kombinieren>> kann wie Kommandozeilentools, [...]>> Wieso eigentlich nicht?
Das ist eine gute Frage. Damit habe ich mich auch schon mal beschäftigt,
weil ich mir dachte: Wäre es nicht cool, wenn man auch auf einer GUI
eben keine mächtige eierlegende Wollmilchsau bräuchte, sondern sich auf
ähnlich simple Weise aus einfachen Einzelbausteinen das, was man
braucht, zusammenstecken könnte? Schon auch, damit man jede
Funktionalität nur einmal implementieren muss und das nicht in jedem
Programm separat nochmal alles drin stecken muss. Mir ist aber keine
Möglichkeit eingefallen, die den Komfort heutiger GUIs mit der
Flexibilität der Kommandozeile sinnvoll verbindet.
> Wenn die "Geschäftslogik" -- z.B. die Aufgabe, Webseiten> zu rendern -- in einem Serverprozess steckt, sollte es> doch kein Problem sein, diesen Server mit einem Clienten> zu kontaktieren, der z.B. die Bookmark-Verwaltung macht.
Ist halt viel Kommunikationsoverhead. Und wenn du an sowas wie Gimp
denkst, wenn du da für jede Funktion ein anderes Programm hast, müssen
die ganzen Bilddaten da immer munter hin und her geschickt werden. Das
ist quasi das Pendant zur Pipe auf der Kommandozeile. Und irgendwo
willst du ja dann doch auch wieder alle Funktionen als Menü zugreifbar
haben, also läuft es am Schluss auch wieder an einer Stelle zusammen.
> Gewinn für den Anwender: Nicht nur die Bookmark-Sammlung> ist dann browserunabhängig -- auch die Bookmark-Verwaltung> ist es.
Sowas ähnliches gibt es inzwischen für Quellcode-Analyse für
Texteditoren, für's Syntax Highlighting, Autovervollständigung,
automatische Fehlererkennung während der Eingabe und so. Da geht es dann
hauptsächlich darum, dass nicht jeder Editor jede Sprache unterstützen
muss, sondern das unabhängig von einander ist.
https://langserver.org/
W.S. schrieb:> Rolf M. schrieb:>> Möchtest du, wenn du ein Bild skalieren und etwas nachschärfen willst,>> dieses dazu erst in einem Tool öffnen, skalieren, speichern, im zweiten>> Tool öffnen,>> Du widersprichst dir selber:
Nein, du hast nur meine Aussage nicht verstanden, vermutlich weil du sie
ohne den Kontext betrachtet hast. Es war eine Antwort darauf:
Egon D. schrieb:> Auf der Kommandozeile gilt "one task -- one tool",> aber bei Programmen mit GUI plötzlich nicht mehr?
Also beispielsweise ein Tool für's Skalieren, ein Tool fürs Schärfen.
Das halte ich aber für wenig zielführend, und genau das war meine
Aussage.
> Wenn man EIN BILD skalieren, nachschärfen etc. möchte, dann macht man das> so. Und gleich anschließend meinst du ein zweites Bild nachschieben zu> müssen. Vielleicht meinst du "wenn man VIELE Bilder skalieren,....".
Nein, meinte ich nicht.
> Gerade bei Bildern ist jedoch jegliche Batch-Abarbeitung eine extrem> fischige Sache. Da kommt es auf das Auge des grafischen Fachmannes an,> ob und in welchem Grade ein Bild überhaupt nachgeschärft oder mehr oder> weniger gesättigt oder sonstwie bearbeitet werden muß, oder inwieweit es> beschnitten werden soll.
Es kommt immer darauf an, was man machen möchte. Aber das geht komplett
am Thema vorbei.
W.S. schrieb:> Gerade bei Bildern ist jedoch jegliche Batch-Abarbeitung> eine extrem fischige Sache.
Du denkst zu eindimensional.
Nachbearbeitung von digitalisierten Druckwerken
(aka "Scans") will niemand von Hand mit der Maus im
GUI machen -- zumindest nicht für mehr als drei
Seiten.
Auf das Auswählen, Schärfen und Überlagern von
hunderten von Astrophotos trifft dasselbe zu.
Rolf M. schrieb:> Das ist eine gute Frage. Damit habe ich mich auch> schon mal beschäftigt, weil ich mir dachte: Wäre> es nicht cool, wenn man auch auf einer GUI eben> keine mächtige eierlegende Wollmilchsau bräuchte,> sondern sich auf ähnlich simple Weise aus einfachen> Einzelbausteinen das, was man braucht, zusammenstecken> könnte?
Genau.
> Schon auch, damit man jede Funktionalität nur einmal> implementieren muss und das nicht in jedem Programm> separat nochmal alles drin stecken muss.
Anstoß für meine Überlegungen war Software für Leiter-
plattenentwurf. Einerseits sind ja die Kernfunktionen,
die die Software leisten muss, immer ziemlich ähnlich.
Andererseits sind die Wünsche, was den Arbeitsablauf
und die Bedienung angeht, teilweise SEHR breit gestreut.
Also wäre es doch nur logisch, wenn man einen Kern hätte,
der die nötigen Transformationen über den Daten vornehmen
kann, und beliebig viele GUIs, die die Daten und die
Operationen so präsentieren, wie der Nutzer das gerade
wünscht. Statt dessen fängt jedes Projekt wieder neu
im Urschleim an, erfindet alles neu und wiederholt auch
jeden denkbaren Fehler...
> Mir ist aber keine Möglichkeit eingefallen, die den> Komfort heutiger GUIs mit der Flexibilität der> Kommandozeile sinnvoll verbindet.
Wüsste ich aus dem Stand auch nicht -- aber es fällt ja
auf, dass m.W. nahezu jede CAD-Software eine integrierte
Scriptsprache hat. Woher das nur kommen mag... :)
>> Wenn die "Geschäftslogik" -- z.B. die Aufgabe, Webseiten>> zu rendern -- in einem Serverprozess steckt, sollte es>> doch kein Problem sein, diesen Server mit einem Clienten>> zu kontaktieren, der z.B. die Bookmark-Verwaltung macht.>> Ist halt viel Kommunikationsoverhead. Und wenn du an sowas> wie Gimp denkst, wenn du da für jede Funktion ein anderes> Programm hast, müssen die ganzen Bilddaten da immer munter> hin und her geschickt werden. Das ist quasi das Pendant> zur Pipe auf der Kommandozeile.
Nee... in der Form ist das natürlich nicht sinnvoll.
Eine Pipe geht gewissermaßen von der Vorstellung eines
m.o.w. unstrukturierten Datenstromes aus, den man durch
verschiedene Filter schickt. Die Vorstellung klappt aber
nicht mehr, wenn es sich um komplexen Daten handelt, auf
die man nacheinander gewisse Operationen anwendet.
Es muss ja auch technisch gar nicht IDENTISCH funktionieren;
Ziel ist ja nur, dass man für den Anwender ähnlichen
Komfort erreicht.
> Und irgendwo willst du ja dann doch auch wieder alle> Funktionen als Menü zugreifbar haben, also läuft es> am Schluss auch wieder an einer Stelle zusammen.
Sicher -- der Trick ist die klare Schnittstelle dazwischen,
denn die ermöglicht, dass man ein GUI durch ein anderes
ersetzen kann.
W.S. schrieb:>> Nur dass niemand von sich aus diese Dateien jemals anfasst.>> Aber offenbar sind eben diese Dateien bei Windows (und eben die Links> bei Linux) für das Funktionieren der ganzen Toolchain notwendig.
Nein, sind sie nicht. Sie sind das Nutzer-Frontend. Ob du nun
arm-none-eabi-gcc oder arm-none-eabi-gcc-8.1.0 aufrufst, ist rein deine
Sache. Wenn du einen davon nie aufrufst, kannst du den auch löschen.
Aber wenn dich das wirklich tiefer interessiert, lass es uns bitte in
einem separaten Thread abhandeln.
W.S. schrieb:> Allenfalls bleibt hier die Frage, ob dem TO außer MSPaint und 'Gimpf'> überhaupt noch irgend etwas bekannt sein könnte. Hier dediziert auf> diesem Gimpff und seinen Ladezeiten noch weiter herumzureiten, wird so> langsam uninteressant.
Für umfangreichere Profi-Programme wie GIMP, Photoshop, ... interessiert
duie Ladezeit sowieso nicht.
Der Profi kommt früh, schaltet die Kiste an und schaltet sie nach 8h
wieder aus. Was interessieren da schon 30sec ?
> Was bleibt, ist eine Vielzahl von Windows-Programmen, mit denen man> Bildbearbeitung betreiben kann. Der TO hätte einfach bloß mal ein wenig> danach suchen müssen (sofern er kein Troll ist).
Ich habe mal in meinen vergangenen Windosen nachgegraben.
Es sind mehr als 10 Bildprogramme, die dem TO genügen würden.
Die Hälfte davon sind Beilagen zu Scannern, Fotodruckern oder
Digiknipsen.
Bei manchen sind die sogar frei.
Wie bei Fuji das MyFinepix-Studio.
Bei CANON muß man zur Erkennung ein Gerät haben. Aber Dank eines
Fotodruckers war das auch kein Problem.
Und dann die Teile von Softpaketen.
Wie bei COREL das Corel-Paint.
Oder beim MS-Office der Picture Manager.
Man muß sich nur mal die Mühe machen, seine vorhandene Software und
Geräte zu sichten.
Programme bis zu 15 Jahre sollten sich auch unter W10 noch installieren
lassen.
Jörg W. schrieb:> Gimp> liest beim Start ein paar Tausend Dateien ein, und das ist etwas, bei> dem Windows erfahrungsgemäß *) langsam ist.>> *) Erfahrung: Projekte mit ein paar hundert Quelldateien compilieren.
Stimmt, das ist ein Aspekt, der unter Windows nicht sonderlich
performant ist. Ein anderer Aspekt, der in beiden Anwendungsfällen eine
Rolle spielen dürfte, ist die reine Speicherverwaltung. Die Entwickler
des Rechenkernels unserer Hauptprodukte führen dazu auf identischer
Hardware sehr umfangreiche Performancetests durch, und mußten leider
feststellen: die Speicherverwaltung unter Windows 7 erreichte dabei
lediglich 70% der Performance unter Ubuntu Linux, die unter Windows 8
sogar nur ungefähr 50%, die von Windows 10 ist wieder besser geworden
und liegt mittlerweile wieder auf dem Niveau von Windows 7 bei etwa 70
%.
Sheeva P. schrieb:> Ein anderer Aspekt, der in beiden Anwendungsfällen eine Rolle spielen> dürfte, ist die reine Speicherverwaltung.
Wobei diese Unterschiede nicht dafür verantwortlich sein können, dass
Gimp unter Windows ein Vielfaches der Startzeit im Vergleich zu Unixen
braucht. Das sind ja eher Unterschiede < 50 % (relativ zueinander).
Jörg W. schrieb:> Sheeva P. schrieb:>> Ein anderer Aspekt, der in beiden Anwendungsfällen eine Rolle spielen>> dürfte, ist die reine Speicherverwaltung.>> Wobei diese Unterschiede nicht dafür verantwortlich sein können, dass> Gimp unter Windows ein Vielfaches der Startzeit im Vergleich zu Unixen> braucht. Das sind ja eher Unterschiede < 50 % (relativ zueinander).
Ich vermute eher, daß es sich um eine Kombination aus beiden Punkten
handelt. Windows ist in verschiedenen Bereichen im Vergleich weniger
performant, und das summiert sich dann halt. Daß MS Office und andere
MS-Produkte schneller starten, hat übrigens ganz früher daran gelegen,
daß große Teile der Software bereits beim Boot und / oder beim Login
geladen und initialisiert wurden und dann unabhängig davon, ob sie
tatsächlich benutzt wurden einfach mal Speicher belegt haben. Wenn die
MS-Programme dann gestartet wurden, sah das natürlich enorm schnell aus.
Keine Ahnung, ob das heute immer noch so gemacht wird, ist mir aber auch
egal: ich hab' ja kein Windows und auf meinen Systemen ist The GIMP in
weniger als zwei Sekunden startklar. Auf einem ollen Q9650 mit ebenso
altem rotierenden Rost als Backend, immerhin in einem SoftRAID... ;-)
Jörg W. schrieb:>> Aber offenbar sind eben diese Dateien bei Windows (und eben die Links>> bei Linux) für das Funktionieren der ganzen Toolchain notwendig.>> Nein, sind sie nicht. Sie sind das Nutzer-Frontend.
Von wegen. Ich war damals bei der Lernbetty exakt darüber mal
gestolpert - und nun kommst du und behauptest einfach, die seien nicht
nötig. Die Namensgebung war übrigens anders: in \bin sowas wie
arm-nonw-eabi-gcc.exe und in \arm-none-eabi\bin dann nur gcc.exe und so
weiter, wenn ich mich recht entsinne.
OK, die olle yagarto-Distribution für Windows mag heutzutage nicht mehr
en vogue sein, also ist das alles nebensächlich, genauso wie die
Diskussion, wie lange denn nun ein Gimpf unter diversen OS zum Starten
braucht.
Der TO hat hier neben dem üblichen Geschnatter ohne eigene
Such-Anstrengungen bereits einiges an Hinweisen erhalten, was es denn so
alles an brauchbaren Programmen gibt.
W.S.
W.S. schrieb:> Die Namensgebung war übrigens anders: in \bin sowas wie> arm-nonw-eabi-gcc.exe und in \arm-none-eabi\bin dann nur gcc.exe und so> weiter, wenn ich mich recht entsinne.
In bin/ stehen die User-Frontends. Verlinkt ist dort nur ${arch}-gcc mit
${arch}-gcc-${version}. Außerdem sind ${arch}-g++ und ${arch}-c++
verlinkt.
In ${arch}/bin/ stehen die Backend-Programme: Assembler, Linker etc. Ja,
die haben auch Links nach bin/, aber letztere sind wiederum
User-Frontend, wenn du also als Nutzer explizit Assembler oder Linker
aufrufen willst. Machst du bloß normalerweise nicht, und der
Compiler-Treiber ruft stets nur die Tools in ${arch}/bin auf. Damit
entsteht das von dir beschworene Problem, dass ein identisches Binary
mehr als einmal geladen werden muss, im normalen Betrieb nicht. (Wie
geschrieben, mit der Ausnahme, dass du Assembler oder Linker manuell
rufst, dann würde es entstehen.) Umgekehrt, ${arch}-objcopy und
${arch}-objdump sind auch verlinkt, aber die ruft der Compiler nie
selbst auf, die rufst du höchstens selbst auf (bspw. aus dem Makefile),
dann werden die aus bin/ geladen.
Jörg W. schrieb:> Machst du bloß normalerweise nicht,...
Laß gut sein, den GCC hab ich seitdem nie wieder angerührt - und was du
da schreibst, klingt mir auch zu sehr von hinten durch die Brust ins
Knie. Normalerweise braucht man für eine Zielplattform auch nur eine
Toolchain mit einem Compiler, einem Linker etc. - und nicht einen Zirkus
aus gegenseitigen Aufrufen. Bin im Nachhinein noch immer heilfroh,
damals das Geld in die Hand genommen zu haben.
Und es war hier ja auch nur, um eine Erklärung zu finden für
unterschiedliche Wartezeiten und Abarbeitungsgeschwindigkeiten. Der
Thread ist dennoch durchaus interessant geworden, werde mir mal bei
Gelegenheit dieses 'sagelight' anschauen. Hatte bislang noch nie davon
gelesen, was aber kein Wunder ist, da ich mit dem Zeug, was ich habe,
durchaus zufrieden bin.
W.S.
Jörg W. schrieb:> Genau das isses auch …
Laß mal gut sein, GCC war und ist nicht mein Ding, gehört auch genauso
wenig zum Topic wie meine jetzt bereits fast leere Flasche Chardonnay
Spätlese 2018 (WG Strub).
W.S.
Mit "Process Monitor" gerade mal spaßeshalber einen Start von gimp unter
Windows geloggt: Es wird bei mir knapp 15.000x CreateFile()* aufgerufen.
Beim sehr grob drüber scrollen am auffälligsten:
- Es werden scheinbar so ziemlich alle *.dlls, die im gimp-Ordner liegen
direkt beim Start geladen (Unter Linux wäre hier möglicherweise davon
schon teilweise etwas durch die Desktopumgebung bereits geladen und im
RAM)
- liest sämtliche Fonts aus C:\Windows\Fonts\ komplett ein
- nudelt den "brushes"-Ordner durch (inklusive einem
"gimp-obsolete-files"-Unterordner)
Die Fonts scheinen beim Start der Haupt-Zeitfresser zu sein.
Software wie LibreOffice scheint mit vielen Fonts zu rechnen und liest
die Fonts bei Programmstart nicht komplett ein und liest die
Font-Dateien erst on-the-fly wenn sie im Dropdown sichtbar werden
(*die API-Funktion gibt einen File-Handle zurück und erzeugt nicht
unbedingt eine Datei)
bluppdidupp schrieb:> Es wird bei mir knapp 15.000x CreateFile()* aufgerufen
Das ist nochmal erheblich mehr als hier bei mir unter FreeBSD. Ich zähle
2613 erfolgreiche Aufrufe von open() bzw. openat().
Das könnte u.U. einen Teil der Zeitunterschiede erklären.
Habe mir jetzt nicht die Mühe gemacht zu klassifizieren, was die 2613
Files alles sind …
Le X. schrieb:> Wäre jetzt interessant wieso die Windows-Version meint, soviele Dateien> einlesen zu müssen.
Yep. Kann mir nicht vorstellen, dass sie so viele tausend Font-Dateien
mehr hat.
Jörg W. schrieb:> bluppdidupp schrieb:>> Es wird bei mir knapp 15.000x CreateFile()* aufgerufen>> Das ist nochmal erheblich mehr als hier bei mir unter FreeBSD. Ich zähle> 2613 erfolgreiche Aufrufe von open() bzw. openat().
Bei mir (unter Linux) waren es bis gerade eben knapp 8000 open[at], der
Großteil davon bezieht sich auf Fonts. Nachdem ich die Fonts mal
ordentlich ausgemistet habe, sind es nur noch 2024, davon 1757
erfolgreich. Der Start von Gimp geht jetzt deutlich schneller, auch mit
vorher gelöschtem Cache.
Die Fonts scheinen also schon eine große Rolle zu spielen.
Le X. schrieb:> Wäre jetzt interessant wieso die Windows-Version meint, soviele Dateien> einlesen zu müssen.
Weil die Programmierer noch eine Win-3.1 Technik benutzen. Da war es
damals üblich die Fonts einzulesen und DIREKT bereit zu stellen. Bis
Win-98 kam es sogar vor das Windows ab einer bestimmten Anzahl an Fonts
gar nicht mehr starte.
Bei modernen Techniken werden nur die Namen der Fonts eingelesen und
(meist) in einen Pulldown zur Verfügung gestellt. Sobald der User mit
der Maus darüber fährt wird (je nach Programm) wird die Font temporär
Geladen und angezeigt.
Windows hatte in älteren Zeiten schwere Speed-Probleme wenn zu viele
Fonts auf den Rechner waren. Heutzutage ist was zwar besser geworden,
aber auch nicht wirklich gut.
Es gibt spezielle "Fontmanager" die versuchen Ordnung in das
Schriftenchaos auf den Rechner zu bringen, und Windows so zu
beschleunigen.
Hier mal ein Link dazu.
https://www.designerinaction.de/typografie/font-manager-schriftarten-verwalten-mac-windows/
Übriges lt. den Internet (ich kenne es nur von Windows) ist das Problem
mit den vielen Fonts System übergreifend.
Schlaumaier schrieb:> Weil die Programmierer noch eine Win-3.1 Technik benutzen. Da war es> damals üblich die Fonts einzulesen und DIREKT bereit zu stellen. Bis> Win-98 kam es sogar vor das Windows ab einer bestimmten Anzahl an Fonts> gar nicht mehr starte.
Die CreateFile()-Syscalls werden ja vom Userspace-Code, also von Gimp,
abgesetzt.
Somit seh ich das Problem mit langen Startzeiten nicht direkt bei
Windows sondern eher in Gimp.
OK, ein CreateFile() ist wohl intern auch weniger performant als ein
open() unter Unixoiden, aber generell müsste Gimp ja nicht direkt alle
Fonts gleich einlesen.
Le X. schrieb:> Somit seh ich das Problem mit langen Startzeiten nicht direkt bei> Windows sondern eher in Gimp.
Klar ist das Problem beim Gimp. Mein Corel-Draw benutzt ja die neue
Methode.
Merke ich daran das es 1-2 Sekunden dauert bis ich die Font
"nachgeladen" bekomme.
Das Grundsätzliche Problem bei Windows ist, das es keine Eier hat. Den
Anspruch "Abwärts kompatibel" bis zum es geht nicht mehr zu sein, lässt
viele alte Routinen in Kernel oder DLL's überleben. Und deshalb ändern
die Coder das nicht. Nach dne Motto "es geht doch".
Schlaumaier schrieb:> Das Grundsätzliche Problem bei Windows ist, das es keine Eier hat. Den> Anspruch "Abwärts kompatibel" bis zum es geht nicht mehr zu sein, lässt> viele alte Routinen in Kernel oder DLL's überleben. Und deshalb ändern> die Coder das nicht. Nach dne Motto "es geht doch".
Das kann man aber nicht Win bzw MS anlasten.
Wer wollte, der konnte noch Mitte der 90er Programme schreiben, die
FCB-basierte Filefunktionen benutzten, obwohl MS seit mehreren
Generationen davon abgeraten hatte.
MS hätte auch die FCB-Unterstützung ab DOS 5 einstellen können und auch
davon absehen, COM-Files zu laden. Oder man erzwingt in jeder Version
die Verwendung neuer, optimierter EXE-Header.
Wie wäre das wohl am Markt angekommen?
michael_ schrieb:> Jack V. schrieb:>> michael_ schrieb:>>> Und die fliegenden Fenster sind ja immer noch da.>>>> Das ist konfigurierbar.>> Aha! Werd mal gucken.
Hab geguckt, wo kann man das?
Übrigens, GIMP braucht unter VISTA auf meinem 939 Testrechner ca. 6sec.
Und der ist nicht gerade schnell.
Etwa genau so lange, wie der FF, EXCEL, ...
Sinnlose Diskussion um paar sec.
michael_ schrieb:> Übrigens, GIMP braucht unter VISTA auf meinem 939 Testrechner ca. 6sec.> Und der ist nicht gerade schnell.> Etwa genau so lange, wie der FF, EXCEL, ...>> Sinnlose Diskussion um paar sec.
Du hast aber schon mitbekommen, dass das offensichtlich sehr von der
Anzahl installierter Fonts abhängt. Das mag damit auf anderen Rechner
ganz anders aussehen als auf deiner Gurke. Insofern war die Diskussion
eher sehr nützlich.
Gerhard
Gerhard schrieb:> Du hast aber schon mitbekommen, dass das offensichtlich sehr von der> Anzahl installierter Fonts abhängt.
Zumindest war das bis GIMP 2.4 so. Aktuell ist es deutlich besser
geworden.
Percy N. schrieb:> Wie wäre das wohl am Markt angekommen?
Frag mal Apple. Die wissen das genau. Die wechseln einfach die
Prozessoren und das wars. Apple User sind reich die können alles neu
kaufen ODER ?
michael_ schrieb:> Übrigens, GIMP braucht unter VISTA auf meinem 939 Testrechner ca. 6sec.> Und der ist nicht gerade schnell.
Die frage ist : Wie viele FONTS hast du darauf. Weil DIE fressen die
Speed. Und die kann man kaum beschleunigen, weil es eine uralte Routine
ist.
ALT :
For i = 1 to an_fonts
Lese ganz Font + ziehe im Speicher
next i
NEU
For i = 1 to an_fonts
Lese FONTNAME + füttere das Pulldown
next i
Sub Font_anzeigen 'wenn user auf Font klickt
lese ganze Font in Speicher
end sub
Bei OFFICE-95 wurde noch die ALT methode benutzt.
Bei OFFICE-98 glaube ich schon die neue, bin mir nicht sicher da ich
damals ein Font-Manager laufen hatte.
-d, --no-data Keine Pinsel, Muster, Farbverläufe usw. laden
2
-f, --no-fonts Keine Schriften laden
3
-s, --no-splash Kein Startfenster anzeigen
Wenn man Gimp also mit -f startet, dann lädt er keine Fonts. Kann ja mal
jemand (bei dem es sonst langsam ist) testen, wie viel schneller er dann
unter Windows lädt.
Das ganze Fonthandling läuft über FontConfig und FreeType.
michael_ schrieb:> Und die fliegenden Fenster sind ja immer noch da.>> Das Konzept ist nicht mein Ding.
Deshalb kann man sie ja auch andocken, wenn man das will...
Von den Calls sind allerdings einige mehrfach hintereinander für die
gleiche Datei und teils ohne direkt folgendes ReadFile(). Vermutlich
werden da teilweise nur Datei-Eigenschaften wie Dateigröße oder sowas
abgerufen und das Handle wieder geschlossen. Ich hatte im Process
Monitor nur sehr grob einmal drüber gescrolled und nicht wirklich
detailliert angeschaut was da tatsächlich jeweils wieviel Zeit frisst
und hier nur erwähnt was beim drüber scrollen ins Auge fiel. Ohne Filter
auf nur CreateFile+ReadFile sieht man da vermutlich auch nochmal etwas
mehr. Bei echtem Interesse also besser selber mal messen und
detaillierter anschauen ;D
Als kleine Referenz: Schriften habe ich "nur" 261 im System (allerdings
ist der Fonts-Ordner laut Explorer 465 MiB groß, die dlls im gimp-Ordner
sind auch schon >250MiB)
Im Vergleich zum älteren Photoshop CS2 startet gimp bei mir minimal
schneller.
Nach schließen und direkt wieder öffnen blitzt das Fonts laden nur sehr
kurz beim Splash-Screen einmal auf und der Start geht deutlich schneller
- und hängt Photoshop im Vergleich komplett ab.
Wirklich relevant ist die Ladezeit für mich persönlich da allerdings
ohnehin nicht - Richtige Bildbearbeitung kommt bei mir eher selten vor.
mspaint oder die Fotos-App sind bei mir wesentlich öfter im Einsatz und
die gehen beide sowieso instant offen ;D
Schlaumaier schrieb:> michael_ schrieb:>> Übrigens, GIMP braucht unter VISTA auf meinem 939 Testrechner ca. 6sec.>> Und der ist nicht gerade schnell.>> Die frage ist : Wie viele FONTS hast du darauf. Weil DIE fressen die> Speed. Und die kann man kaum beschleunigen, weil es eine uralte Routine> ist.
Da ist ein gut gebrauchtes MS-Office drauf. Ca. 300 Fonds.
npn schrieb:> Deshalb kann man sie ja auch andocken, wenn man das will...
Der Geist ist ja willig, nur wie?
Ist GIMP-2.
michael_ schrieb:> Ist GIMP-2.
Ganz präzise Angabe. Umfasst alle Versionen der letzten 16 Jahre:
https://www.gimp.org/about/history.html
Das Ein-Fenster-Layout kam erst vor vier Jahren oder so rein (Edit: acht
Jahre sind es schon. Ich fühle mich alt :| ). Wenn du also mit einer
Mumie hantieren solltest, wirst du’s dort nicht finden.
Eine Mumie sicher nicht.
Habe es erst aufgrund dieses Threads installiert.
Hab nachgesehen. Es ist die 2.8.13.
Warum machst du mir da einen Vorwurf?
Es wäre eine späte Einsicht, dass man mehr Freunde ohne die fliegenden
Fenster gewinnt.
Mein aktuelles System will ich mir mit GIMP nicht vollmüllen.
Brauche das Monster nicht.
