Open GoogleCodeExporter opened 9 years ago
Patch to update user memory management in OpenJPEG2.1
Original comment by slmis...@gmail.com
on 13 Jun 2014 at 11:01
Attachments:
Original comment by antonin
on 15 Jul 2014 at 8:27
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
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
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
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
Original comment by antonin
on 16 Sep 2014 at 3:55
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
@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
@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:
Original issue reported on code.google.com by
slmis...@gmail.com
on 13 Jun 2014 at 10:52Attachments: