Weird behavior, GC 8.5

[Robert Poland]

Thorsten, Two issues; 1. I am editing a 256 Grays (8 bit) 1200DPI image (679 KB). I have the Foreground set to white and the Background set to black. I select an area and hit Delete. Oops, the selected area turns black. I meant to have the Background white. I do an undo. The area remains selected. I hit the X reverse the colors and again hit Delete. The erased area turns black. I MUST do an undo, exit the selected area, then hit the X to reverse the colors. 2. Same 256 Grays (8 bit) 1200DPI image (679 KB). editing is very very very very slow. Checking with Activity Monitor I see that the Real Memory used is 7.33 GB and the Virtual Memory used is 8.75 GB. Quitting the application and restarting helps but only for a moment. Do I need to go back to an earlier version to cure these issues? If so which one? TIA, Robert Poland - Fort Collins, CO

[thorstenlemke]

Hi Robert,can I please get the file for testing?Thorsten On 09.12.2012, at 20:18, Robert Poland <rpoland@usa.net> wrote:   Thorsten, Two issues; 1. I am editing a 256 Grays (8 bit) 1200DPI image (679 KB). I have the Foreground set to white and the Background set to black. I select an area and hit Delete. Oops, the selected area turns black. I meant to have the Background white. I do an undo. The area remains selected. I hit the X reverse the colors and again hit Delete. The erased area turns black. I MUST do an undo, exit the selected area, then hit the X to reverse the colors. 2. Same 256 Grays (8 bit) 1200DPI image (679 KB). editing is very very very very slow.

[Robert Poland]

On Dec 9, 2012, at 1:22 PM, Thorsten Lemke <lemke@lemkesoft.de> wrote:Hi Robert,can I please get the file for testing?ThorstenOn 09.12.2012, at 20:18, Robert Poland <rpoland@usa.net> wrote:Thorsten,Two issues;1. I am editing a 256 Grays (8 bit) 1200DPI image (679 KB). I have the Foreground set to white and the Background set to black. I select an area and hit Delete. Oops, the selected area turns black. I meant to have the Background white. I do an undo. The area remains selected. I hit the X reverse the colors and again hit Delete. The erased area turns black. I MUST do an undo, exit the selected area, then hit the X to reverse the colors. 2. Same 256 Grays (8 bit) 1200DPI image (679 KB). editing is very very very very slow.Robert Poland - Fort Collins, CO

[thorstenlemke]

Hi Robert,the performance is caused by the undo action.I added now some optimizations:http://www.lemkesoft.org/beta.htmlThorsten On 09.12.2012, at 21:31, Robert Poland <rpoland@usa.net> wrote:On Dec 9, 2012, at 1:22 PM, Thorsten Lemke <lemke@lemkesoft.de> wrote:Hi Robert,can I please get the file for testing?ThorstenOn 09.12.2012, at 20:18, Robert Poland <rpoland@usa.net> wrote:Thorsten,

[Robert Poland]

Thanks Thorsten, I appreciate the speed increase but the Undo quit working all together. After a short editing session the Ram usage is now at 712 MB and the Virtual is at 824 MB. Guess I'll go back to the previous 8.5. On Dec 10, 2012, at 1:05 PM, Thorsten Lemke <lemke@lemkesoft.de> wrote: > > > Hi Robert, > > the performance is caused by the undo action. > I added now some optimizations: > > http://www.lemkesoft.org/beta.html > > Thorsten > > > On 09.12.2012, at 21:31, Robert Poland <rpoland@usa.net> wrote: > >> >> On Dec 9, 2012, at 1:22 PM, Thorsten Lemke <lemke@lemkesoft.de> wrote: >> >>> >>> >>> Hi Robert, >>> >>> can I please get the file for testing? >>> >>> Thorsten >>> >>> On 09.12.2012, at 20:18, Robert Poland <rpoland@usa.net> wrote: >>> >>>> Thorsten, Robert Poland - Fort Collins, CO

[thorstenlemke]

Hello Robert,you can change the behaviour in the prefs part general/memory.Thorsten On 10.12.2012, at 22:58, Robert Poland <rpoland@usa.net> wrote:   Thanks Thorsten, I appreciate the speed increase but the Undo quit working all together. After a short editing session the Ram usage is now at 712 MB and the Virtual is at 824 MB. Guess I'll go back to the previous 8.5. On Dec 10, 2012, at 1:05 PM, Thorsten Lemke <lemke@lemkesoft.de> wrote: > > > Hi Robert, > > the performance is caused by the undo action. > I added now some optimizations: > > http://www.lemkesoft.org/beta.html > > Thorsten > > > On 09.12.2012, at 21:31, Robert Poland <rpoland@usa.net> wrote: > >> >> On Dec 9, 2012, at 1:22 PM, Thorsten Lemke <lemke@lemkesoft.de> wrote: >> >>> 

[Robert Poland]

Thorsten, The need to turn OFF Ubdo severely cripples GraphicConverter. On Dec 11, 2012, at 12:40 AM, Thorsten Lemke <lemke@lemkesoft.de> wrote: > Hello Robert, > > you can change the behaviour in the prefs part general/memory. > > Thorsten > > > > On 10.12.2012, at 22:58, Robert Poland <rpoland@usa.net> wrote: > >> Thanks Thorsten, >> >> I appreciate the speed increase but the Undo quit working all together. >> >> After a short editing session the Ram usage is now at 712 MB and the Virtual is at 824 MB. >> >> Guess I'll go back to the previous 8.5. >> >> On Dec 10, 2012, at 1:05 PM, Thorsten Lemke <lemke@lemkesoft.de> wrote: >> >> > >> > >> > Hi Robert, >> > >> > the performance is caused by the undo action. >> > I added now some optimizations: >> > >> > http://www.lemkesoft.org/beta.html >> > >> > Thorsten >> > >> > >> > On 09.12.2012, at 21:31, Robert Poland <rpoland@usa.net> wrote: >> > >> >> >> >> On Dec 9, 2012, at 1:22 PM, Thorsten Lemke <lemke@lemkesoft.de> wrote: >> >> Robert Poland - Fort Collins, CO

[thorstenlemke]

Hello,the image size is 100MB. So, it has to be cached (memory/disk) before each change.But the memory cache of 10 steps should be no problem if you have 4 GB or more of main memory.Thorsten On 11.12.2012, at 14:59, Robert Poland <rpoland@usa.net> wrote:   Thorsten, The need to turn OFF Ubdo severely cripples GraphicConverter. On Dec 11, 2012, at 12:40 AM, Thorsten Lemke <lemke@lemkesoft.de> wrote: > Hello Robert, > > you can change the behaviour in the prefs part general/memory. > > Thorsten > > > 

[Robert Poland]

Thorsten, The file size is on;y 764 KB, not 100 MB. Since I changed TV provider there were many changes to make to the image, many more than 10. I find it easier to cut and paste instead of redrawing, How goes one fix the massive memory usage, other than quitting and restarting GraphicConverter? On Dec 11, 2012, at 7:02 AM, Thorsten Lemke <lemke@lemkesoft.de> wrote: > > > Hello, > > the image size is 100MB. So, it has to be cached (memory/disk) before each change. > But the memory cache of 10 steps should be no problem if you have 4 GB or more of main memory. > > Thorsten > > On 11.12.2012, at 14:59, Robert Poland <rpoland@usa.net> wrote: > >> Thorsten, >> >> The need to turn OFF Ubdo severely cripples GraphicConverter. >> >> On Dec 11, 2012, at 12:40 AM, Thorsten Lemke <lemke@lemkesoft.de> wrote: >> >> > Hello Robert, >> > >> > you can change the behaviour in the prefs part general/memory. >> > >> > Thorsten >> > Robert Poland - Fort Collins, CO

[thorstenlemke]

Hello,the file size in memory is around 100 MB. Please look at the information window.I have to open the file as 8 bit grayscale (because Cocoa does no longer support bitmap). The size in memory has to be cached for undo.Thorsten On 11.12.2012, at 15:14, Robert Poland <rpoland@usa.net> wrote:   Thorsten, The file size is on;y 764 KB, not 100 MB. Since I changed TV provider there were many changes to make to the image, many more than 10. I find it easier to cut and paste instead of redrawing, How goes one fix the massive memory usage, other than quitting and restarting GraphicConverter? On Dec 11, 2012, at 7:02 AM, Thorsten Lemke <lemke@lemkesoft.de> wrote: >