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 = = = ======================================================================== |
|
|
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. > (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 |
|
|
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 = = = ======================================================================== |
|
|
John M McIntosh wrote:
> 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. Yes, that's what I mean by "severely rewriting the plugin". You'd be effectively writing a different plugin altogether and accompanying image side code. My point above is that it wouldn't make sense to try to beat the existing jpeg prims into submission for whatever the platform API looks like. On the other hand I have found that the most flexible way to deal with fast image reading is to have a "pure" Smalltalk version and then an "acceleration primitive" that takes a form of the correct format and decodes the input data into the form. This way, if there is anything problematic in the image data, the prim just fails and you deal with the (few) remaining situations by hand, but the common case is blindingly fast. For Teleplace, we have such acceleration prims for example in both PNG and GIF readers (we read *lots* of those ;-) and it would be trivial to provide a similar primitive entry point in the existing JPEG read/writer. Whether these prims are then implemented by platform or generic means is less important because the interface is just one primitive taking a form and a byte array and either succeeding or failing. Cheers, - Andreas |
«
Return to Squeak - Dev
|
1 view|%1 views
| Free forum by Nabble | Edit this page |