[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
|