JPEG plugin.
Locked
 
|
I'm looking at the JPEG plugin and wondering?
(a) Should I convert that to using the os-x platforms JPEG implementation, versus our usage of the source from the "Independent JPEG Group's software" ? (b) Should we consider upgrading the VMs from version "6b 27- Mar-1998" to the more current "release 7 of 27-Jun-2009" since we store the source in the VM SVN tree at the moment. I've not looked but (a) Apple might have a private implementation that could be faster since it would likely use hardware vector services. (b) Relying on the system libraries for conversion means fixes for security issues get prompt attention, versus our non-attention now. -- = = = ======================================================================== John M. McIntosh <[hidden email]> Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com = = = ======================================================================== _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
On 2009-11-03, at 1:01 PM, Andreas Raab wrote: > John M McIntosh wrote: >> I'm looking at the JPEG plugin and wondering? >> (a) Should I convert that to using the os-x platforms JPEG >> implementation, versus our usage of the source from the >> "Independent JPEG Group's software"? > > Seems like a bad trade unless you want to severely rewrite the > plugin interface (making it effectively a new plugin). The current > interface is tied specifically to the IJGs implementation with > internal structures and functions being exposed fairly directly. Yes, however in working with Sophie we noticed *most* interfacing is done via ImageReadWriter which supports a generic interface for creating or reading files or streams. The choice of which class to use is based on iterating over the subclasses and asking who can do the work, it never appeared that people messed about with the JPEG read/write class other than asking for magic decoding/encoding. For Sophie we choose to override this and provided an interface that worked with Apple's quicktime for os-x and Windows to read *lots* of graphics formats and provide us with a resulting form. No doubt I could do the same given if os-x and some flavour of the VM then do a different call path. > >> (b) Should we consider upgrading the VMs from version "6b 27- >> Mar-1998" to the more current "release 7 of 27-Jun-2009" since we >> store the source in the VM SVN tree at the moment. > > That sounds like a good idea. > >> I've not looked but >> (a) Apple might have a private implementation that could be faster >> since it would likely use hardware vector services. > > Almost certainly. Intel's performance prims can make JPEG stuff > quite a bit faster already. > >> (b) Relying on the system libraries for conversion means fixes for >> security issues get prompt attention, versus our non-attention now. > > I'm not sure about this. The IJGs code has been quite robust and to > my knowledge no exploits have ever been published. OTOH, Microsofts > implementation seems to have been sucessfully attacked in the past, > so it's a bit questionable whether using the OS vendors > implementation would necessarily be more secure than the IJGs version. > > Cheers, > - Andreas -- = = = ======================================================================== John M. McIntosh <[hidden email]> Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com = = = ======================================================================== _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
«
Return to Pharo Smalltalk Developers
|
1 view|%1 views
| Free forum by Nabble | Edit this page |