[Discuss] Review and improve graphics memory handling

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
19 messages Options
Reply | Threaded
Open this post in threaded view
|

[Discuss] Review and improve graphics memory handling

Rory O'Farrell

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=7&t=41271&p=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.

 
--
Rory O'Farrell <[hidden email]>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [Discuss] Review and improve graphics memory handling

Kay Schenk-2


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=7&t=41271&p=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.
--
--------------------------------------------
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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [Discuss] Review and improve graphics memory handling

Armin.Le.Grand@me.com
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=7&t=41271&p=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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [Discuss] Review and improve graphics memory handling

Rory O'Farrell
On Tue, 26 May 2015 10:19:07 +0200
"[hidden email]" <[hidden email]> 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=7&t=41271&p=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: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>


--
Rory O'Farrell <[hidden email]>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [Discuss] Review and improve graphics memory handling

Armin.Le.Grand@me.com
Hi Rory,

On 26.05.2015 10:37, Rory O'Farrell wrote:

> On Tue, 26 May 2015 10:19:07 +0200
> "[hidden email]" <[hidden email]> 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=7&t=41271&p=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: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

SOS
Reply | Threaded
Open this post in threaded view
|

Re: [Discuss] Review and improve graphics memory handling

SOS
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, [hidden email] wrote:

> Hi Rory,
>
> On 26.05.2015 10:37, Rory O'Farrell wrote:
>> On Tue, 26 May 2015 10:19:07 +0200
>> "[hidden email]" <[hidden email]> 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=7&t=41271&p=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: [hidden email]
>>> For additional commands, e-mail: [hidden email]
>>>
>>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [Discuss] Review and improve graphics memory handling

Kay Schenk-2
In reply to this post by Armin.Le.Grand@me.com


On 05/26/2015 01:19 AM, [hidden email] 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=7&t=41271&p=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: [hidden email]
> For additional commands, e-mail: [hidden email]
>

--
--------------------------------------------
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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [Discuss] Review and improve graphics memory handling

Nancy K-2
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 1"4. 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 <[hidden email]>
To: [hidden email] 
Sent: Tuesday, May 26, 2015 2:22 PM
Subject: Re: [Discuss] Review and improve graphics memory handling



On 05/26/2015 01:19 AM, [hidden email] 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=7&t=41271&p=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: [hidden email]
> For additional commands, e-mail: [hidden email]

-- 
--------------------------------------------
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: [hidden email]
For additional commands, e-mail: [hidden email]



Reply | Threaded
Open this post in threaded view
|

Re: [Discuss] Review and improve graphics memory handling

Nancy K-2
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 <[hidden email]>
 To: "[hidden email]" <[hidden email]>
 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 1"4. 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 <[hidden email]>
To: [hidden email] 
Sent: Tuesday, May 26, 2015 2:22 PM
Subject: Re: [Discuss] Review and improve graphics memory handling





On 05/26/2015 01:19 AM, [hidden email] 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=7&t=41271&p=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: [hidden email]
> For additional commands, e-mail: [hidden email]

-- 
--------------------------------------------
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: [hidden email]
For additional commands, e-mail: [hidden email]




Reply | Threaded
Open this post in threaded view
|

Re: [Discuss] Review and improve graphics memory handling

Armin.Le.Grand@me.com
In reply to this post by SOS
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, [hidden email] wrote:
>> Hi Rory,
>>
>> On 26.05.2015 10:37, Rory O'Farrell wrote:
>>> On Tue, 26 May 2015 10:19:07 +0200
>>> "[hidden email]" <[hidden email]> 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=7&t=41271&p=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: [hidden email]
>>>> For additional commands, e-mail: [hidden email]
>>>>
>>>>
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [Discuss] Review and improve graphics memory handling

Armin.Le.Grand@me.com
In reply to this post by SOS
upps - sorry, Fernand, I took the wrong string as your name in the last
reply.
alg

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

SOS
Reply | Threaded
Open this post in threaded view
|

Re: [Discuss] Review and improve graphics memory handling

SOS
In reply to this post by Armin.Le.Grand@me.com
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, [hidden email] 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, [hidden email] wrote:
>>> Hi Rory,
>>>
>>> On 26.05.2015 10:37, Rory O'Farrell wrote:
>>>> On Tue, 26 May 2015 10:19:07 +0200
>>>> "[hidden email]" <[hidden email]> 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=7&t=41271&p=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: [hidden email]
>>>>> For additional commands, e-mail: [hidden email]
>>>>>
>>>>>
>>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: [hidden email]
>>> For additional commands, e-mail: [hidden email]
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [Discuss] Review and improve graphics memory handling

Andrea Pescetti-2
In reply to this post by Armin.Le.Grand@me.com
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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [Discuss] Review and improve graphics memory handling

Armin.Le.Grand@me.com
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: [hidden email]
> For additional commands, e-mail: [hidden email]
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [Discuss] Review and improve graphics memory handling

Andrea Pescetti-2
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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [Discuss] Review and improve graphics memory handling

Armin.Le.Grand@me.com
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: [hidden email]
> For additional commands, e-mail: [hidden email]
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [Discuss] Review and improve graphics memory handling

Andrea Pescetti-2
On 02/06/2015 [hidden email] 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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

RE: [Discuss] Review and improve graphics memory handling

Dennis E. Hamilton
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:[hidden email]]
Sent: Sunday, June 7, 2015 18:57
To: [hidden email]
Subject: Re: [Discuss] Review and improve graphics memory handling

On 02/06/2015 [hidden email] 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: [hidden email]
For additional commands, e-mail: [hidden email]


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

RE: [Discuss] Review and improve graphics memory handling

Kay Schenk-2
On Jun 8, 2015 8:46 AM, "Dennis E. Hamilton" <[hidden email]>
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:[hidden email]]
> Sent: Sunday, June 7, 2015 18:57
> To: [hidden email]
> Subject: Re: [Discuss] Review and improve graphics memory handling
>
> On 02/06/2015 [hidden email] 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: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>