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.
Microsoft Word. Kann zuschneiden, freistellen, Helligkeit, Kontrast
Tim schrieb: > Mir geht es dabei in der Hauptsache um Kontrast- und > Helligkeitsänderungen. https://www.irfanview.com/main_what_is_ger.htm
Thomas L. schrieb: > Paint.NET https://www.getpaint.net schon mal angeschaut? Klingt erst mal gut, aber wenn ich auf free download klicke, lande ich hier https://www.getpaint.net/download.html#download und dann hier: https://www.microsoft.com/de-de/p/paintnet/9nbhcs1lx4r0?cid=pdn_www_download&rtc=1&activetab=pivot:overviewtab (und MS will Kohle)
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.
:
Bearbeitet durch User
Photo Filtre. Die Weiterentwicklung des guten alten Paint Shop Pro. http://www.photofiltre-studio.com/pf7-en.htm
FastStone nutze ich seit vielen Jahren für einfache Bildbearbeitung aus der DSLR https://www.faststone.org/FSViewerDetail.htm
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.
PhotoFiltre. Einfach & intuitiv zu bedienen. https://de.wikipedia.org/wiki/PhotoFiltre www.photofiltre.com
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.
Tim schrieb: > Klingt erst mal gut, aber wenn ich auf free download klicke, lande ich > hier > https://www.getpaint.net/download.html#download > und dann hier: > https://www.microsoft.com/de-de/p/paintnet/9nbhcs1lx4r0?cid=pdn_www_download&rtc=1&activetab=pivot:overviewtab > (und MS will Kohle) Dann klick auf den Link bei dem unter Price "Free" steht.
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.
iche schrieb: > Microsoft Word. > Kann zuschneiden, freistellen, Helligkeit, Kontrast Und mit Paint geht Briefe schreiben super...
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
so schrieb: >> Klingt erst mal gut, aber wenn ich auf free download klicke, lande ich >> hier >> https://www.getpaint.net/download.html#download >> und dann hier: >> > https://www.microsoft.com/de-de/p/paintnet/9nbhcs1lx4r0?cid=pdn_www_download&rtc=1&activetab=pivot:overviewtab >> (und MS will Kohle) > > Dann klick auf den Link bei dem unter Price "Free" steht. Habe ich gemacht und runtergeladen. Dann bekommt man die Datei paint.net.4.2.13.install.exe. Die habe ich online auf Viren getestet: https://www.virustotal.com/gui/file/6a77ab1f93e0a3ec2dc82efa9e43fe6587b76460e2ed21049716f8064b3ccdac/detection Dabei sagt das Virusprogramm DrWeb
1 | Trojan.Siggen9.56433 |
die anderen Virusprogramme sagen nix. Installieren oder lieber nicht???
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.
Finde ich nicht nett, dass man für einen kleinen Tippfehler gleich so verungimpft wird.
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...
Tim schrieb: > Thomas L. schrieb: >> Paint.NET https://www.getpaint.net schon mal angeschaut? > > Klingt erst mal gut, aber wenn ich auf free download klicke, lande ich > hier > https://www.getpaint.net/download.html#download > und dann hier: > https://www.microsoft.com/de-de/p/paintnet/9nbhcs1lx4r0?cid=pdn_www_download&rtc=1&activetab=pivot:overviewtab > (und MS will Kohle) https://www.dotpdn.com/files/paint.net.4.2.13.install.zip Ein Klick in der Spalte "Download" und nicht in der Spalte "Mirror" hilft dort weiter.
Erwin D. schrieb: > Bei mir kommt da ein Link zu einem Zip-File... Das Ergebnis der entpackten .exe bei virustotal deckt sich mit dem weiter oben.
Erwin D. 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... Genau, Download als zip und entpackt gibt es die Datei. M. P. schrieb: > https://www.dotpdn.com/files/paint.net.4.2.13.install.zip > > Ein Klick in der Spalte "Download" und nicht in der Spalte "Mirror" > hilft dort weiter. Ja, hatte ich schon rutergeladen, Danke! Dann bekommt man die Datei mit der wahrscheinlich falsch positiven Trojanerwarnung Trojan.Siggen9.56433. Beitrag "Re: Gibt es ein Bildbearbeitungsprogramm zwischen Paint und Gimpf?"
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
Frank L. schrieb: > Die Weiterentwicklung des guten alten Paint Shop Pro. Wie belieben? Corel verkauft derzeit PSP 2021: http://help.corel.com/paintshop-pro/how-to/de/official-help/index.html#page/Corel_PaintShop_Pro/new_in_paintshop_pro.html Was soll PF damit zu tun haben? Und so toll ist ein derartiges Programm ohne Weißabgleich auch nicht ...
Percy N. schrieb: > Wie belieben? > Corel verkauft derzeit PSP 2021: Aber nicht für 10 Euro als EWIG-Version. Sonst bestelle ich das noch heute.
Percy N. schrieb: > Was soll PF damit zu tun haben? Naja, gilt ja als "Maß aller Dinge" in der Bildbearbeitung.
Beitrag #6433584 wurde von einem Moderator gelöscht.
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.
Angehängte Dateien:
-
iv.PNG
17 KB
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 …
:
Bearbeitet durch User
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:
1 | j@uriah 105% ldd `which gerbv` |
2 | /usr/local/bin/gerbv: |
3 | libgerbv.so.1 => /usr/local/lib/libgerbv.so.1 (0x80068a000) |
4 | libm.so.5 => /lib/libm.so.5 (0x8008b3000) |
5 | libgtk-x11-2.0.so.0 => /usr/local/lib/libgtk-x11-2.0.so.0 (0x800a00000) |
6 | libgdk-x11-2.0.so.0 => /usr/local/lib/libgdk-x11-2.0.so.0 (0x801050000) |
7 | libpangocairo-1.0.so.0 => /usr/local/lib/libpangocairo-1.0.so.0 (0x8008e5000) |
8 | libatk-1.0.so.0 => /usr/local/lib/libatk-1.0.so.0 (0x8008f5000) |
9 | libgdk_pixbuf-2.0.so.0 => /usr/local/lib/libgdk_pixbuf-2.0.so.0 (0x800925000) |
10 | libgio-2.0.so.0 => /usr/local/lib/libgio-2.0.so.0 (0x801308000) |
11 | libpangoft2-1.0.so.0 => /usr/local/lib/libpangoft2-1.0.so.0 (0x80094c000) |
12 | libpango-1.0.so.0 => /usr/local/lib/libpango-1.0.so.0 (0x800965000) |
13 | libgobject-2.0.so.0 => /usr/local/lib/libgobject-2.0.so.0 (0x8014d6000) |
14 | libglib-2.0.so.0 => /usr/local/lib/libglib-2.0.so.0 (0x80152d000) |
15 | libintl.so.8 => /usr/local/lib/libintl.so.8 (0x8009b6000) |
16 | libfontconfig.so.1 => /usr/local/lib/libfontconfig.so.1 (0x801662000) |
17 | libfreetype.so.6 => /usr/local/lib/libfreetype.so.6 (0x8016ae000) |
18 | libcairo.so.2 => /usr/local/lib/libcairo.so.2 (0x801772000) |
19 | libthr.so.3 => /lib/libthr.so.3 (0x8009c5000) |
20 | libc.so.7 => /lib/libc.so.7 (0x8018b0000) |
21 | libXrender.so.1 => /usr/local/lib/libXrender.so.1 (0x801ca6000) |
22 | libXinerama.so.1 => /usr/local/lib/libXinerama.so.1 (0x801eaf000) |
23 | libXi.so.6 => /usr/local/lib/libXi.so.6 (0x8020b1000) |
24 | libXrandr.so.2 => /usr/local/lib/libXrandr.so.2 (0x8009f2000) |
25 | libXcursor.so.1 => /usr/local/lib/libXcursor.so.1 (0x8020c3000) |
26 | libXext.so.6 => /usr/local/lib/libXext.so.6 (0x8020d1000) |
27 | libgmodule-2.0.so.0 => /usr/local/lib/libgmodule-2.0.so.0 (0x8020e6000) |
28 | libX11.so.6 => /usr/local/lib/libX11.so.6 (0x8020ec000) |
29 | libXcomposite.so.1 => /usr/local/lib/libXcomposite.so.1 (0x802235000) |
30 | libXdamage.so.1 => /usr/local/lib/libXdamage.so.1 (0x80223a000) |
31 | libXfixes.so.3 => /usr/local/lib/libXfixes.so.3 (0x80223f000) |
32 | libz.so.6 => /lib/libz.so.6 (0x802444000) |
33 | libharfbuzz.so.0 => /usr/local/lib/libharfbuzz.so.0 (0x802460000) |
34 | libfribidi.so.0 => /usr/local/lib/libfribidi.so.0 (0x802545000) |
35 | libffi.so.7 => /usr/local/lib/libffi.so.7 (0x802564000) |
36 | libpcre.so.1 => /usr/local/lib/libpcre.so.1 (0x80256f000) |
37 | libiconv.so.2 => /usr/local/lib/libiconv.so.2 (0x802612000) |
38 | libexpat.so.1 => /usr/local/lib/libexpat.so.1 (0x802711000) |
39 | libbz2.so.4 => /usr/lib/libbz2.so.4 (0x80293b000) |
40 | libpixman-1.so.0 => /usr/local/lib/libpixman-1.so.0 (0x802951000) |
41 | libEGL.so.1 => /usr/local/lib/libEGL.so.1 (0x802a20000) |
42 | libpng16.so.16 => /usr/local/lib/libpng16.so.16 (0x802a54000) |
43 | libxcb-shm.so.0 => /usr/local/lib/libxcb-shm.so.0 (0x802a92000) |
44 | libxcb.so.1 => /usr/local/lib/libxcb.so.1 (0x802a98000) |
45 | libxcb-render.so.0 => /usr/local/lib/libxcb-render.so.0 (0x802ac5000) |
46 | libGL.so.1 => /usr/local/lib/libGL.so.1 (0x802ad6000) |
47 | libgraphite2.so.3 => /usr/local/lib/libgraphite2.so.3 (0x802b6c000) |
48 | libgbm.so.1 => /usr/local/lib/libgbm.so.1 (0x802b98000) |
49 | libglapi.so.0 => /usr/local/lib/libglapi.so.0 (0x802ba9000) |
50 | libX11-xcb.so.1 => /usr/local/lib/libX11-xcb.so.1 (0x802c09000) |
51 | libxcb-dri2.so.0 => /usr/local/lib/libxcb-dri2.so.0 (0x802c0d000) |
52 | libxcb-xfixes.so.0 => /usr/local/lib/libxcb-xfixes.so.0 (0x802c14000) |
53 | libdrm.so.2 => /usr/local/lib/libdrm.so.2 (0x802c1e000) |
54 | libxcb-dri3.so.0 => /usr/local/lib/libxcb-dri3.so.0 (0x802c35000) |
55 | libxcb-present.so.0 => /usr/local/lib/libxcb-present.so.0 (0x802c3c000) |
56 | libxcb-sync.so.1 => /usr/local/lib/libxcb-sync.so.1 (0x802c41000) |
57 | libxshmfence.so.1 => /usr/local/lib/libxshmfence.so.1 (0x802c4a000) |
58 | libXau.so.6 => /usr/local/lib/libXau.so.6 (0x802c4e000) |
59 | libXdmcp.so.6 => /usr/local/lib/libXdmcp.so.6 (0x802c54000) |
60 | libxcb-glx.so.0 => /usr/local/lib/libxcb-glx.so.0 (0x802e59000) |
61 | libXxf86vm.so.1 => /usr/local/lib/libXxf86vm.so.1 (0x802e77000) |
62 | libc++.so.1 => /usr/lib/libc++.so.1 (0x80307b000) |
63 | libcxxrt.so.1 => /lib/libcxxrt.so.1 (0x803148000) |
64 | libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x80316a000) |
Nichtsdestotrotz startet das auf Windows innerhalb von Millisekunden.
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...
Gimpf lädt bei mir in unter 2 sec - bei geleertem FS Cache.
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 ;-)
auf meinem Raspberry dauert es genau 5 Sekunden ohne das was vorgeladen ist.
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.
Beitrag #6433987 wurde von einem Moderator gelöscht.
Beitrag #6434030 wurde von einem Moderator gelöscht.
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.
Beitrag #6434143 wurde von einem Moderator gelöscht.
Gimpf (sic!) braucht doch auch unter Linux eine halbe Ewigkeit für den Startvorgang. Selbst mit SSD.
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
Beitrag #6434192 wurde von einem Moderator gelöscht.
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.
Beitrag #6434224 wurde von einem Moderator gelöscht.
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.
Jack V. schrieb: > michael_ schrieb: >> Und die fliegenden Fenster sind ja immer noch da. > > Das ist konfigurierbar. Aha! Werd mal gucken.
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 ...
:
Bearbeitet durch User
Sagen wir mal so: "Einfach, primitiv und doch geschmacklos."
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
1 | mytool | grep xyz | sort -n | cut -d1 -f' ' |
Beitrag #6435284 wurde von einem Moderator gelöscht.
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
:
Bearbeitet durch User
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 …
:
Bearbeitet durch Moderator
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.
:
Bearbeitet durch User
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... ;-)
alle Programme die unten links in der "Schnellstartleiste" sind, werden wie du beschreibst im Speicher vorgehalten(in Windows)
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.
Um mla wieder zum Thema was beizutragen: Für Fotobearbeitung ist Sagelight bei mir nicht mehr wegzudenken. https://www.sagelighteditor.com/
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.
W.S. schrieb: > Normalerweise braucht man für eine Zielplattform auch nur eine Toolchain > mit einem Compiler, einem Linker etc. Genau das isses auch …
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 …
Wäre jetzt interessant wieso die Windows-Version meint, soviele Dateien einlesen zu müssen.
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.
Btw.:
1 | -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.
:
Bearbeitet durch User
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.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.