RE: [Discuss] Review and improve graphics memory handling
On Jun 8, 2015 8:46 AM, Dennis E. Hamilton dennis.hamil...@acm.org wrote: I've never understood this business of having multiple releases as progressions on the same code branch. It seems far more confusing than having a branch or tag that corresponds to the release identifier. Actually before 4.1.1, we did use tags if memory serves. I just assumed we could do this again for 4.1.2 unless there was some reason not to. I also find the revision cut used for 4.1.1 confusing. In reality, we could do a tag for it I think. It also helps if there is a need for a patch release at a particular branch. It also makes check-out of a specific release branch easier. And it is easy to confirm the archive of the released source against its SVN. Although there is a lot of code involved, I thought SVN used a Copy on Write strategy so copying code into a branch does not create actual copies but links, with copies made only when a difference is introduced at either end of the link. Am I mistaken? I don't have much skin in this game. It just strikes me that there is a high risk of confusion and possible error this way. Even if a 412 is built from a copy of 411, rather than the trunk, with changes then cherry-picked into it, it seems easier to inspect and to understand. - Dennis -Original Message- From: Andrea Pescetti [mailto:pesce...@apache.org] Sent: Sunday, June 7, 2015 18:57 To: dev@openoffice.apache.org Subject: Re: [Discuss] Review and improve graphics memory handling On 02/06/2015 armin.le.gr...@me.com wrote: AFAIU AOO410 branch goes on for 411, 412, 413... versions. One branch for next mid-number change, e.g. AOO420 would need a new one. For AOO411 we have no extra branch AFAIK, only a revision number in AOO410 branch. I would keep that schema - the goal of micro releases is minor changes/stability, no need for a new branch I'm OK with this. I will commit changes to the existing AOO410 branch instead of creating AOO412 then. Regards, Andrea. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
RE: [Discuss] Review and improve graphics memory handling
I've never understood this business of having multiple releases as progressions on the same code branch. It seems far more confusing than having a branch or tag that corresponds to the release identifier. It also helps if there is a need for a patch release at a particular branch. It also makes check-out of a specific release branch easier. And it is easy to confirm the archive of the released source against its SVN. Although there is a lot of code involved, I thought SVN used a Copy on Write strategy so copying code into a branch does not create actual copies but links, with copies made only when a difference is introduced at either end of the link. Am I mistaken? I don't have much skin in this game. It just strikes me that there is a high risk of confusion and possible error this way. Even if a 412 is built from a copy of 411, rather than the trunk, with changes then cherry-picked into it, it seems easier to inspect and to understand. - Dennis -Original Message- From: Andrea Pescetti [mailto:pesce...@apache.org] Sent: Sunday, June 7, 2015 18:57 To: dev@openoffice.apache.org Subject: Re: [Discuss] Review and improve graphics memory handling On 02/06/2015 armin.le.gr...@me.com wrote: AFAIU AOO410 branch goes on for 411, 412, 413... versions. One branch for next mid-number change, e.g. AOO420 would need a new one. For AOO411 we have no extra branch AFAIK, only a revision number in AOO410 branch. I would keep that schema - the goal of micro releases is minor changes/stability, no need for a new branch I'm OK with this. I will commit changes to the existing AOO410 branch instead of creating AOO412 then. Regards, Andrea. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: [Discuss] Review and improve graphics memory handling
On 02/06/2015 armin.le.gr...@me.com wrote: AFAIU AOO410 branch goes on for 411, 412, 413... versions. One branch for next mid-number change, e.g. AOO420 would need a new one. For AOO411 we have no extra branch AFAIK, only a revision number in AOO410 branch. I would keep that schema - the goal of micro releases is minor changes/stability, no need for a new branch I'm OK with this. I will commit changes to the existing AOO410 branch instead of creating AOO412 then. Regards, Andrea. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: [Discuss] Review and improve graphics memory handling
Hi Andrea, AFAIU AOO410 branch goes on for 411, 412, 413... versions. One branch for next mid-number change, e.g. AOO420 would need a new one. For AOO411 we have no extra branch AFAIK, only a revision number in AOO410 branch. I would keep that schema - the goal of micro releases is minor changes/stability, no need for a new branch from my POV, but this are just my 2 ct... Sincerely, alg On 31.05.2015 17:38, Andrea Pescetti wrote: On 29/05/2015 Armin.Le.Grand wrote: will check if it's in AOO410 branch... Actually, I thought we had consensus on creating a AOO412 branch for OpenOffice 4.1.2. I see you have now committed the fix to AOO410. Of course, this is not really important, it is far more important that the release comes some steps closer, thanks Armin for the fix! But I recommend to settle the branch discussion on this list so that we know whether to reuse (once again) AOO410 as we did for OpenOffice 4.1.1 or to have a dedicated branch for OpenOffice 4.1.2. Regards, Andrea. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: [Discuss] Review and improve graphics memory handling
On 29/05/2015 Armin.Le.Grand wrote: will check if it's in AOO410 branch... Actually, I thought we had consensus on creating a AOO412 branch for OpenOffice 4.1.2. I see you have now committed the fix to AOO410. Of course, this is not really important, it is far more important that the release comes some steps closer, thanks Armin for the fix! But I recommend to settle the branch discussion on this list so that we know whether to reuse (once again) AOO410 as we did for OpenOffice 4.1.1 or to have a dedicated branch for OpenOffice 4.1.2. Regards, Andrea. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: [Discuss] Review and improve graphics memory handling
Hi, will check if it's in AOO410 branch... Sincerely, alg On 28.05.2015 07:53, Andrea Pescetti wrote: Armin.Le.Grand wrote: it should be http://bz.apache.org/ooo/show_bug.cgi?id=125519 which is fixed and in master, would be a candidate for AOO412, too. OK, I added target 4.1.2 to that issue so that we can start identifying what to actually put into 4.1.2. We do have a Release blocker flag for 4.1.2, but it entails a more complex workflow which I'm not sure we want at the moment. Regards, Andrea. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: [Discuss] Review and improve graphics memory handling
upps - sorry, Fernand, I took the wrong string as your name in the last reply. alg - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: [Discuss] Review and improve graphics memory handling
Hi greetz, cannot say if this is related - probably not. If you have a reproducable (short?) way to show this, please open a task and describe it there. Thanks in advance, this is important. Sincerely, alg On 26.05.2015 15:26, SOS wrote: Armin, Do not know if his is related but there is a memory leak when using ImageControls in dialogs. When filling a ImageControl with image data, it eats memory and only release this memory after restarting OO. greetz Fernand On 26/05/2015 14:45, armin.le.gr...@me.com wrote: Hi Rory, On 26.05.2015 10:37, Rory O'Farrell wrote: On Tue, 26 May 2015 10:19:07 +0200 armin.le.gr...@me.com armin.le.gr...@me.com wrote: Hi, it should be http://bz.apache.org/ooo/show_bug.cgi?id=125519 which is fixed and in master, would be a candidate for AOO412, too. Sincerely, alg Thank you for the link to Bugzilla, Armin. That bug might answer the crash problem which seems to be Windows related; as most of our Users are using Windows that is good. However this does not address the overall problem of the increasing slow memory management as memory allocated and used by OO increases when large files are processed, be they of graphics or just text file handling. It may be that the fundamental logic underlying the file structure and its processing will not permit of any improvement in this (I don't know - it is currently beyond my knowledge), but often a change in the algorithm used will allow an improvement in a program bottleneck. Has anyone any thoughts on that aspect? Yes, constantly. For 32bit AOO (Windows unfortunately) the 4GB mem quickly gets filled with modern bitmaps. The mentioned fix resolves that by limiting used mem for loaded pics - not much else to be done without bigger redesigns and on 32bit. Rewrites of this aspect are surely welcome! Sincerely, alg On 26.05.2015 00:28, Kay Schenk wrote: On 05/25/2015 11:03 AM, Rory O'Farrell wrote: There are constant reports of images going missing in OO Writer. The problem is not consistently reproducible, but is there nevertheless. A recent report suggests it might be memory related: https://forum.openoffice.org/en/forum/viewtopic.php?f=7t=41271p=353246#p353246 It is also informative to move back along that thread for other instances of the problem. I doubt that we can dismiss all occurrences of this problem as finger trouble (i.e., improper user usage). Might it be time to consider increasing the maximum memory allocation for graphics (currently 256 MB) and to review the memory management of the suggested compilers? Also, in case the problem arises from background processing which has not completed on shut down of OO, ought a please wait flag be displayed, a flag specifically keyed to any such background process? In these days of large memory 256MB is a very small allocation. Having observed OO's use of memory with large text (not graphics) files I note that its allocation and consumption of memory is increasingly slower as the amount of memory used by it increases. It is most certainly not linear - I have no accurate method of deciding if the increase in slowness is geometric or even exponential. I found John Ha's analyses and comments back from Apr, 2014 very informative. And, his final followup on Jun 7, 2014 certainly indicates the problem stems from exceeding the graphic memory limits. I couldn't find an actual issue that directly related to this so I will enter one, and reference this thread. Maybe that will help raise attention to it. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: [Discuss] Review and improve graphics memory handling
Armin, Just tried manualy , but not reproducable on windows8. So it is solved or onlyhappening when using the API. Not worthy to lose more time on it. Sorry Fernand On 27/05/2015 10:36, armin.le.gr...@me.com wrote: Hi greetz, cannot say if this is related - probably not. If you have a reproducable (short?) way to show this, please open a task and describe it there. Thanks in advance, this is important. Sincerely, alg On 26.05.2015 15:26, SOS wrote: Armin, Do not know if his is related but there is a memory leak when using ImageControls in dialogs. When filling a ImageControl with image data, it eats memory and only release this memory after restarting OO. greetz Fernand On 26/05/2015 14:45, armin.le.gr...@me.com wrote: Hi Rory, On 26.05.2015 10:37, Rory O'Farrell wrote: On Tue, 26 May 2015 10:19:07 +0200 armin.le.gr...@me.com armin.le.gr...@me.com wrote: Hi, it should be http://bz.apache.org/ooo/show_bug.cgi?id=125519 which is fixed and in master, would be a candidate for AOO412, too. Sincerely, alg Thank you for the link to Bugzilla, Armin. That bug might answer the crash problem which seems to be Windows related; as most of our Users are using Windows that is good. However this does not address the overall problem of the increasing slow memory management as memory allocated and used by OO increases when large files are processed, be they of graphics or just text file handling. It may be that the fundamental logic underlying the file structure and its processing will not permit of any improvement in this (I don't know - it is currently beyond my knowledge), but often a change in the algorithm used will allow an improvement in a program bottleneck. Has anyone any thoughts on that aspect? Yes, constantly. For 32bit AOO (Windows unfortunately) the 4GB mem quickly gets filled with modern bitmaps. The mentioned fix resolves that by limiting used mem for loaded pics - not much else to be done without bigger redesigns and on 32bit. Rewrites of this aspect are surely welcome! Sincerely, alg On 26.05.2015 00:28, Kay Schenk wrote: On 05/25/2015 11:03 AM, Rory O'Farrell wrote: There are constant reports of images going missing in OO Writer. The problem is not consistently reproducible, but is there nevertheless. A recent report suggests it might be memory related: https://forum.openoffice.org/en/forum/viewtopic.php?f=7t=41271p=353246#p353246 It is also informative to move back along that thread for other instances of the problem. I doubt that we can dismiss all occurrences of this problem as finger trouble (i.e., improper user usage). Might it be time to consider increasing the maximum memory allocation for graphics (currently 256 MB) and to review the memory management of the suggested compilers? Also, in case the problem arises from background processing which has not completed on shut down of OO, ought a please wait flag be displayed, a flag specifically keyed to any such background process? In these days of large memory 256MB is a very small allocation. Having observed OO's use of memory with large text (not graphics) files I note that its allocation and consumption of memory is increasingly slower as the amount of memory used by it increases. It is most certainly not linear - I have no accurate method of deciding if the increase in slowness is geometric or even exponential. I found John Ha's analyses and comments back from Apr, 2014 very informative. And, his final followup on Jun 7, 2014 certainly indicates the problem stems from exceeding the graphic memory limits. I couldn't find an actual issue that directly related to this so I will enter one, and reference this thread. Maybe that will help raise attention to it. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: [Discuss] Review and improve graphics memory handling
Armin.Le.Grand wrote: it should be http://bz.apache.org/ooo/show_bug.cgi?id=125519 which is fixed and in master, would be a candidate for AOO412, too. OK, I added target 4.1.2 to that issue so that we can start identifying what to actually put into 4.1.2. We do have a Release blocker flag for 4.1.2, but it entails a more complex workflow which I'm not sure we want at the moment. Regards, Andrea. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: [Discuss] Review and improve graphics memory handling
the link if you would like to try: www.udemy.com/courses Nancy Web Design Free 24 hour pass to lynda.com. Video courses on SEO, CMS, Design and Software Courses From: Nancy K nancythirt...@yahoo.com.INVALID To: dev@openoffice.apache.org dev@openoffice.apache.org Sent: Tuesday, May 26, 2015 4:55 PM Subject: Re: [Discuss] Review and improve graphics memory handling I am not sure if this is the same problem, but it might be since it has to do with graphics. I tried to copy/paste (Ctrl V) the list of graphic images describing courses on this page onto a blank page in OpenOffice 4.1.1Writer :Best Online Courses | Udemy | | | | | | | | | Best Online Courses | UdemyUdemy is the world's largest destination for online courses. Browse the featured courses on Udemy and start learning a new skill today. | | | | View on www.udemy.com | Preview by Yahoo | | | | | My system: Running Win7 Professional 64 bit Operating SystemIntel Core i5-2400 CPU 3.1 ghz; 4 GB RAM installed memory Results after several attempts:1.Each attempt placed the outline boxes and links on the blank page in Writer. 2.Then as it tried to catch up placing the images into place AOO crashed. 3. Alert notice 'OpenOffice Document Recovery' pops up Due to an unexpected error, OpenOffice crashed. All the files you were working on will now be saved. The next time OpenOffice is launched, your files will be recovered automatically. The following files will be recovered: Untitled 14. Selecting OK gave me two scenarios a. Non responsive after progress bar halfway through b. Progress bar never started saving5. Closed and restarted Writer 6. Open Office Document Recovery failed7. Clicking 'NEXT' to get the Error Report Tool opened up a blank page in Writer Nancy Nancy Web Design Free 24 hour pass to lynda.com. Video courses on SEO, CMS, Design and Software Courses From: Kay Schenk kay.sch...@gmail.com To: dev@openoffice.apache.org Sent: Tuesday, May 26, 2015 2:22 PM Subject: Re: [Discuss] Review and improve graphics memory handling On 05/26/2015 01:19 AM, armin.le.gr...@me.com wrote: Hi, it should be http://bz.apache.org/ooo/show_bug.cgi?id=125519 which is fixed and in master, would be a candidate for AOO412, too. Sincerely, alg OK. Thanks. This didn't seem to directly relate to just graphic images (but overall size ) so I didn't find it. On 26.05.2015 00:28, Kay Schenk wrote: On 05/25/2015 11:03 AM, Rory O'Farrell wrote: There are constant reports of images going missing in OO Writer. The problem is not consistently reproducible, but is there nevertheless. A recent report suggests it might be memory related: https://forum.openoffice.org/en/forum/viewtopic.php?f=7t=41271p=353246#p353246 It is also informative to move back along that thread for other instances of the problem. I doubt that we can dismiss all occurrences of this problem as finger trouble (i.e., improper user usage). Might it be time to consider increasing the maximum memory allocation for graphics (currently 256 MB) and to review the memory management of the suggested compilers? Also, in case the problem arises from background processing which has not completed on shut down of OO, ought a please wait flag be displayed, a flag specifically keyed to any such background process? In these days of large memory 256MB is a very small allocation. Having observed OO's use of memory with large text (not graphics) files I note that its allocation and consumption of memory is increasingly slower as the amount of memory used by it increases. It is most certainly not linear - I have no accurate method of deciding if the increase in slowness is geometric or even exponential. I found John Ha's analyses and comments back from Apr, 2014 very informative. And, his final followup on Jun 7, 2014 certainly indicates the problem stems from exceeding the graphic memory limits. I couldn't find an actual issue that directly related to this so I will enter one, and reference this thread. Maybe that will help raise attention to it. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org -- MzK We can all sleep easy at night knowing that somewhere at any given time, the Foo Fighters are out there fighting Foo. -- David Letterman - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: [Discuss] Review and improve graphics memory handling
I am not sure if this is the same problem, but it might be since it has to do with graphics. I tried to copy/paste (Ctrl V) the list of graphic images describing courses on this page onto a blank page in OpenOffice 4.1.1Writer :Best Online Courses | Udemy | | | | | | | | | Best Online Courses | UdemyUdemy is the world's largest destination for online courses. Browse the featured courses on Udemy and start learning a new skill today. | | | | View on www.udemy.com | Preview by Yahoo | | | | | My system: Running Win7 Professional 64 bit Operating SystemIntel Core i5-2400 CPU 3.1 ghz; 4 GB RAM installed memory Results after several attempts:1.Each attempt placed the outline boxes and links on the blank page in Writer. 2.Then as it tried to catch up placing the images into place AOO crashed. 3. Alert notice 'OpenOffice Document Recovery' pops up Due to an unexpected error, OpenOffice crashed. All the files you were working on will now be saved. The next time OpenOffice is launched, your files will be recovered automatically. The following files will be recovered: Untitled 14. Selecting OK gave me two scenarios a. Non responsive after progress bar halfway through b. Progress bar never started saving5. Closed and restarted Writer 6. Open Office Document Recovery failed7. Clicking 'NEXT' to get the Error Report Tool opened up a blank page in Writer Nancy Nancy Web Design Free 24 hour pass to lynda.com. Video courses on SEO, CMS, Design and Software Courses From: Kay Schenk kay.sch...@gmail.com To: dev@openoffice.apache.org Sent: Tuesday, May 26, 2015 2:22 PM Subject: Re: [Discuss] Review and improve graphics memory handling On 05/26/2015 01:19 AM, armin.le.gr...@me.com wrote: Hi, it should be http://bz.apache.org/ooo/show_bug.cgi?id=125519 which is fixed and in master, would be a candidate for AOO412, too. Sincerely, alg OK. Thanks. This didn't seem to directly relate to just graphic images (but overall size ) so I didn't find it. On 26.05.2015 00:28, Kay Schenk wrote: On 05/25/2015 11:03 AM, Rory O'Farrell wrote: There are constant reports of images going missing in OO Writer. The problem is not consistently reproducible, but is there nevertheless. A recent report suggests it might be memory related: https://forum.openoffice.org/en/forum/viewtopic.php?f=7t=41271p=353246#p353246 It is also informative to move back along that thread for other instances of the problem. I doubt that we can dismiss all occurrences of this problem as finger trouble (i.e., improper user usage). Might it be time to consider increasing the maximum memory allocation for graphics (currently 256 MB) and to review the memory management of the suggested compilers? Also, in case the problem arises from background processing which has not completed on shut down of OO, ought a please wait flag be displayed, a flag specifically keyed to any such background process? In these days of large memory 256MB is a very small allocation. Having observed OO's use of memory with large text (not graphics) files I note that its allocation and consumption of memory is increasingly slower as the amount of memory used by it increases. It is most certainly not linear - I have no accurate method of deciding if the increase in slowness is geometric or even exponential. I found John Ha's analyses and comments back from Apr, 2014 very informative. And, his final followup on Jun 7, 2014 certainly indicates the problem stems from exceeding the graphic memory limits. I couldn't find an actual issue that directly related to this so I will enter one, and reference this thread. Maybe that will help raise attention to it. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org -- MzK We can all sleep easy at night knowing that somewhere at any given time, the Foo Fighters are out there fighting Foo. -- David Letterman - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: [Discuss] Review and improve graphics memory handling
On Tue, 26 May 2015 10:19:07 +0200 armin.le.gr...@me.com armin.le.gr...@me.com wrote: Hi, it should be http://bz.apache.org/ooo/show_bug.cgi?id=125519 which is fixed and in master, would be a candidate for AOO412, too. Sincerely, alg Thank you for the link to Bugzilla, Armin. That bug might answer the crash problem which seems to be Windows related; as most of our Users are using Windows that is good. However this does not address the overall problem of the increasing slow memory management as memory allocated and used by OO increases when large files are processed, be they of graphics or just text file handling. It may be that the fundamental logic underlying the file structure and its processing will not permit of any improvement in this (I don't know - it is currently beyond my knowledge), but often a change in the algorithm used will allow an improvement in a program bottleneck. Has anyone any thoughts on that aspect? On 26.05.2015 00:28, Kay Schenk wrote: On 05/25/2015 11:03 AM, Rory O'Farrell wrote: There are constant reports of images going missing in OO Writer. The problem is not consistently reproducible, but is there nevertheless. A recent report suggests it might be memory related: https://forum.openoffice.org/en/forum/viewtopic.php?f=7t=41271p=353246#p353246 It is also informative to move back along that thread for other instances of the problem. I doubt that we can dismiss all occurrences of this problem as finger trouble (i.e., improper user usage). Might it be time to consider increasing the maximum memory allocation for graphics (currently 256 MB) and to review the memory management of the suggested compilers? Also, in case the problem arises from background processing which has not completed on shut down of OO, ought a please wait flag be displayed, a flag specifically keyed to any such background process? In these days of large memory 256MB is a very small allocation. Having observed OO's use of memory with large text (not graphics) files I note that its allocation and consumption of memory is increasingly slower as the amount of memory used by it increases. It is most certainly not linear - I have no accurate method of deciding if the increase in slowness is geometric or even exponential. I found John Ha's analyses and comments back from Apr, 2014 very informative. And, his final followup on Jun 7, 2014 certainly indicates the problem stems from exceeding the graphic memory limits. I couldn't find an actual issue that directly related to this so I will enter one, and reference this thread. Maybe that will help raise attention to it. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org -- Rory O'Farrell ofarr...@iol.ie - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: [Discuss] Review and improve graphics memory handling
Hi, it should be http://bz.apache.org/ooo/show_bug.cgi?id=125519 which is fixed and in master, would be a candidate for AOO412, too. Sincerely, alg On 26.05.2015 00:28, Kay Schenk wrote: On 05/25/2015 11:03 AM, Rory O'Farrell wrote: There are constant reports of images going missing in OO Writer. The problem is not consistently reproducible, but is there nevertheless. A recent report suggests it might be memory related: https://forum.openoffice.org/en/forum/viewtopic.php?f=7t=41271p=353246#p353246 It is also informative to move back along that thread for other instances of the problem. I doubt that we can dismiss all occurrences of this problem as finger trouble (i.e., improper user usage). Might it be time to consider increasing the maximum memory allocation for graphics (currently 256 MB) and to review the memory management of the suggested compilers? Also, in case the problem arises from background processing which has not completed on shut down of OO, ought a please wait flag be displayed, a flag specifically keyed to any such background process? In these days of large memory 256MB is a very small allocation. Having observed OO's use of memory with large text (not graphics) files I note that its allocation and consumption of memory is increasingly slower as the amount of memory used by it increases. It is most certainly not linear - I have no accurate method of deciding if the increase in slowness is geometric or even exponential. I found John Ha's analyses and comments back from Apr, 2014 very informative. And, his final followup on Jun 7, 2014 certainly indicates the problem stems from exceeding the graphic memory limits. I couldn't find an actual issue that directly related to this so I will enter one, and reference this thread. Maybe that will help raise attention to it. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: [Discuss] Review and improve graphics memory handling
Hi Rory, On 26.05.2015 10:37, Rory O'Farrell wrote: On Tue, 26 May 2015 10:19:07 +0200 armin.le.gr...@me.com armin.le.gr...@me.com wrote: Hi, it should be http://bz.apache.org/ooo/show_bug.cgi?id=125519 which is fixed and in master, would be a candidate for AOO412, too. Sincerely, alg Thank you for the link to Bugzilla, Armin. That bug might answer the crash problem which seems to be Windows related; as most of our Users are using Windows that is good. However this does not address the overall problem of the increasing slow memory management as memory allocated and used by OO increases when large files are processed, be they of graphics or just text file handling. It may be that the fundamental logic underlying the file structure and its processing will not permit of any improvement in this (I don't know - it is currently beyond my knowledge), but often a change in the algorithm used will allow an improvement in a program bottleneck. Has anyone any thoughts on that aspect? Yes, constantly. For 32bit AOO (Windows unfortunately) the 4GB mem quickly gets filled with modern bitmaps. The mentioned fix resolves that by limiting used mem for loaded pics - not much else to be done without bigger redesigns and on 32bit. Rewrites of this aspect are surely welcome! Sincerely, alg On 26.05.2015 00:28, Kay Schenk wrote: On 05/25/2015 11:03 AM, Rory O'Farrell wrote: There are constant reports of images going missing in OO Writer. The problem is not consistently reproducible, but is there nevertheless. A recent report suggests it might be memory related: https://forum.openoffice.org/en/forum/viewtopic.php?f=7t=41271p=353246#p353246 It is also informative to move back along that thread for other instances of the problem. I doubt that we can dismiss all occurrences of this problem as finger trouble (i.e., improper user usage). Might it be time to consider increasing the maximum memory allocation for graphics (currently 256 MB) and to review the memory management of the suggested compilers? Also, in case the problem arises from background processing which has not completed on shut down of OO, ought a please wait flag be displayed, a flag specifically keyed to any such background process? In these days of large memory 256MB is a very small allocation. Having observed OO's use of memory with large text (not graphics) files I note that its allocation and consumption of memory is increasingly slower as the amount of memory used by it increases. It is most certainly not linear - I have no accurate method of deciding if the increase in slowness is geometric or even exponential. I found John Ha's analyses and comments back from Apr, 2014 very informative. And, his final followup on Jun 7, 2014 certainly indicates the problem stems from exceeding the graphic memory limits. I couldn't find an actual issue that directly related to this so I will enter one, and reference this thread. Maybe that will help raise attention to it. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: [Discuss] Review and improve graphics memory handling
On 05/26/2015 01:19 AM, armin.le.gr...@me.com wrote: Hi, it should be http://bz.apache.org/ooo/show_bug.cgi?id=125519 which is fixed and in master, would be a candidate for AOO412, too. Sincerely, alg OK. Thanks. This didn't seem to directly relate to just graphic images (but overall size ) so I didn't find it. On 26.05.2015 00:28, Kay Schenk wrote: On 05/25/2015 11:03 AM, Rory O'Farrell wrote: There are constant reports of images going missing in OO Writer. The problem is not consistently reproducible, but is there nevertheless. A recent report suggests it might be memory related: https://forum.openoffice.org/en/forum/viewtopic.php?f=7t=41271p=353246#p353246 It is also informative to move back along that thread for other instances of the problem. I doubt that we can dismiss all occurrences of this problem as finger trouble (i.e., improper user usage). Might it be time to consider increasing the maximum memory allocation for graphics (currently 256 MB) and to review the memory management of the suggested compilers? Also, in case the problem arises from background processing which has not completed on shut down of OO, ought a please wait flag be displayed, a flag specifically keyed to any such background process? In these days of large memory 256MB is a very small allocation. Having observed OO's use of memory with large text (not graphics) files I note that its allocation and consumption of memory is increasingly slower as the amount of memory used by it increases. It is most certainly not linear - I have no accurate method of deciding if the increase in slowness is geometric or even exponential. I found John Ha's analyses and comments back from Apr, 2014 very informative. And, his final followup on Jun 7, 2014 certainly indicates the problem stems from exceeding the graphic memory limits. I couldn't find an actual issue that directly related to this so I will enter one, and reference this thread. Maybe that will help raise attention to it. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org -- MzK We can all sleep easy at night knowing that somewhere at any given time, the Foo Fighters are out there fighting Foo. -- David Letterman - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
