Radosław Sokół pisze:
> Osadnik pisze:
>> TC, InkScape, IrfanView, GIMP, Paint.NET, Google Earth, Firefox z
>
> InkScape, GIMP i Paint.NET są koszmarnie nieefektywne pamię-
> ciowo niestety. Szczególnie Paint.NET pewnie, bo korzysta z
> maszyny wirtualnej .NET.
>
> PS. Koniecznie musisz mieć trzy programy graficzne otwarte
> jednocześnie?
w Paint.Net robie proste i szybkie przekształcenia do png (w gimpie robi
sie to dłużej a inkscape nie ma edytora rastrowego)
Stad szybkie przełączanie Paint.Net leży w tle i po zapisaniu zamykam
pliki bo owe pliki czyta bardzo szybko. InkScape jest otwarty ciągle -
nie ma co sie bawić w otwieranie i zamykanie trwa to barzo długo jak
również przygotowanie sie do kolejnych korekcji. Wystarczy ze pracuje
sie z plikami SVG powyżej 500KB.
>
>> otwartymi 30 zakładkami, Notepad++, SpeedCrunch, ThunderBird,
>> FoxitReader, Excel, Word.
>
> Trudno mi wierzyć, że co 5 minut przełączasz się z GIMPa na
> Worda, potem na Excela, a potem jeszcze coś sprawdzasz w
> Google Earth.
co 5 minut nie. Jednak może ci sie to wydawać proste to tak w Wordzie ma
symbole topograficzne wraz z opisami, z google earth biorę obraz ze
zdjęć lotniczych, a w excelu mam dane podręczne dotyczące tego co rysuję
(rzadko korzystanie ale skoro excel zajmuje w pamięci niewiele to nie
jest to jakieś szaleństwo)
>
>> Tak sobie muszę radzić by co i rusz nie szorować dyskami otwierając
>> programy. Najlepiej było by kupić 8GB RAM i było by po zabawie ale -
>> no właśnie nie ma gdzie ich włożyć a nowy komputer to sprawa bardzo
>> odległa.
>
> Ja bym zmienił sposób korzystania z aplikacji. Lepiej mieć
> przez pół godziny szybszy komputer, a potem poczekać 5 minut
> nawet na uruchomienie potrzebnego programu, niż przez te 30
> minut się męczyć ze swapowaniem.
30 minut szybszy komputer - nie jest w teraz powolnie a jedynie system
mógłby żwawiej reagować na polecenie suspend że zaraz po kliknięciu
przerzucał by pamięć programu od razu do pliku wymiany a z pliku wymiany
wyciągał to co zostało wrzucone do niego gdy brakło RAMu.
Received on Sun Jan 24 12:15:03 2010
To archiwum zostało wygenerowane przez hypermail 2.1.8 : Sun 24 Jan 2010 - 12:42:02 MET