Update 2 to memory management

[GoogleCodeExporter]

This is the next update to bug 253 
(https://code.google.com/p/openjpeg/issues/detail?id=253) and patches on top of 
OpenJPEG2.1.

This patch propagates the codec to all areas where memory management is used 
and also means that the existing code can be further extended to swap out 
fprintf statements for the correct callback message.

The patch has been regression tested using the ghostscript test files.

Original issue reported on code.google.com by slmis...@gmail.com on 13 Jun 2014 at 10:52

Attachments:

• mem21_jun_13.patch

[GoogleCodeExporter]

Patch to update user memory management in OpenJPEG2.1

Original comment by slmis...@gmail.com on 13 Jun 2014 at 11:01

Attachments:

• mem21_jun_13.patch

[GoogleCodeExporter]

Original comment by antonin on 15 Jul 2014 at 8:27

• Changed state: Accepted
• Added labels: Priority-High
• Removed labels: Priority-Medium

[GoogleCodeExporter]

Hi Shailesh,
Your patch drastically modifies the OpenJPEG API ... So at first glance I must 
say I'm reluctant to apply it. Could you give details on what are the benefits 
of the new memory management you propose and if there is a way to get (some of) 
the same benefits without modifying so much the API ?
Thanks

Original comment by antonin on 17 Jul 2014 at 8:46

[GoogleCodeExporter]

The existing memory management code allows the user to swap out generic
function calls for user specific calls but does not account for the memory
being accessed. This patch allows he user to define their own chunk of
memory so that they have greater control and this in turn means that the
code is thread safe.

A side benefit of this is that all routes that have been updated because of
this can now use the error printing functionality that has only partially
been implemented by yourselves.

Drop me a line if you have further questions, please note I am off on
holiday from the 25th July till the 3rd of August.

Shailesh

Original comment by slmis...@gmail.com on 21 Jul 2014 at 8:44

[GoogleCodeExporter]

Hi All,

It has been a month since our last contact, can you tell me if this patch
is still progressing or do you need some more information?

Shailesh

Original comment by slmis...@gmail.com on 18 Aug 2014 at 7:31

[GoogleCodeExporter]

Hi All,

Is it possible to get some kind of confirmation that you are still looking
into this?

Shailesh

Original comment by slmis...@gmail.com on 26 Aug 2014 at 12:57

[GoogleCodeExporter]

Original comment by antonin on 16 Sep 2014 at 3:55

[GoogleCodeExporter]

We (the Ghostscript dev team - Shailesh has been looking at this on our behalf) 
are getting to the point where we feel it's going to be necessary to fork the 
OpenJPEG code to satisfy our memory management requirements.

Whilst that's not a route we take lightly, we're not seeing much progress on 
(nor enthusiasm for) moving this forward "properly".

Chris

Original comment by chris.j....@googlemail.com on 26 Sep 2014 at 9:14

[GoogleCodeExporter]

@Chris: a few elements from the OpenJPEG side:
 - we are very few people managing the contributions from outside, with very little time available. Moreover we were almost offline for two months during july and august. I know that sounds a bit weird in our times but that's the way it is. So it's not a question of enthusiasm, it's a question of available free time (free, as in "non-paid"). 
 - we definitely want OpenJPEG to move forward, that's why I asked in September for people willing to review the provided patches. Matthieu answered and already helped a lot. In the mean time, we had several security vulnerabilities provided by Foxit that are kept private on the issue tracker, for obvious reasons.
 - as I wrote earlier, the patch provided by Shailesh drastically modifies the OpenJPEG API. Either there is a way to provide a patch that does not modify so much the API, either I need more review on the original patch before applying it.
 - I you cannot wait any longer, I perfectly understand, please fork: I still hope you will merge back in the future.
 - A way to boost OpenJPEG development in the past was to fund an engineer during a few days to speed-up progress on all high-priority issues. Mathieu (Malaterre) did this already very successfully. If you have any way to fund the project, feel free to contact me.

Original comment by antonin on 29 Sep 2014 at 9:41

[GoogleCodeExporter]

@Chris,

Would the API proposed in either of the attach patch be ok ?
I'd rather stick with optB than optA.

Original comment by m.darb...@gmail.com on 1 Oct 2014 at 9:13

Attachments:

• issue356.optA.patch
• issue356.optB.patch