[squeak-dev] Re: JPEG plugin.

Andreas Raab andreas.raab at gmx.de
Wed Nov 4 01:17:43 UTC 2009


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



More information about the Squeak-dev mailing list