JPEGReadWriter2, BitBlt and reusing previously allocated bitmaps

 

Hello everyone, 

Working on JPEGReadWriter2 I noticed that both reading and writing primitives include a sanity check that ensures that the source/destination Smalltalk bitmap has the exact size in bytes needed, instead of checking that its size is at least that needed. Some BitBlt primitives perform the same check, thus not allowing operations with forms with associated bitmaps with a size greater than needed. 

When performing operations with images, and specially when such images are large in size, actually processing the images takes a small fraction of the time it takes to perform the whole operation, while allocating and deallocating correctly sized bitmaps takes much longer. If one would wish to process a series of similarly sized images (with a definite maximum size), it would be desirable to allocate a bitmap big enough to hold any of them only once and then reuse it, thus avoiding the aforementioned cost. Checking that source and destination bitmaps are big enough instead of checking that their size is exactly that which is expected would allow that optimization.

A brief exploration of BitBlt and JPEGReadWriter2's code, accompanied with some experimenting of what would happen if such sanity checks were modified as proposed, has lead me to thinking that these changes would be benefitial. I haven't observed any undesirable side effects (meaning, nothing seems to have blown up :)). However, I'm inexperienced in working with the VM, so it's rather expectable that I miss something :) Your input on the topic would be extremely appreciated.

The attached changesets contain the proposed set of changes.

Cheers!

-Laura Perez Cerrato

Done.

Thanks Laura!

Dave


>  Hi David, Hi All,
>
>    I'd like Laura to be added as a committer to source.squeak.org/VMMaker.

>
> On Wed, Jun 15, 2016 at 7:28 AM, Laura Perez Cerrato <
> [hidden email]> wrote:
>
>>
>> Hello everyone,
>>
>> Working on JPEGReadWriter2 I noticed that both reading and writing
>> primitives include a sanity check that ensures that the
>> source/destination
>> Smalltalk bitmap has the exact size in bytes needed, instead of checking
>> that its size is at least that needed. Some BitBlt primitives perform
>> the
>> same check, thus not allowing operations with forms with associated
>> bitmaps
>> with a size greater than needed.
>>
>> When performing operations with images, and specially when such images
>> are
>> large in size, actually processing the images takes a small fraction of
>> the
>> time it takes to perform the whole operation, while allocating and
>> deallocating correctly sized bitmaps takes much longer. If one would
>> wish
>> to process a series of similarly sized images (with a definite maximum
>> size), it would be desirable to allocate a bitmap big enough to hold any
>> of
>> them only once and then reuse it, thus avoiding the aforementioned cost.
>> Checking that source and destination bitmaps are big enough instead of
>> checking that their size is exactly that which is expected would allow
>> that
>> optimization.
>>
>> A brief exploration of BitBlt and JPEGReadWriter2's code, accompanied
>> with
>> some experimenting of what would happen if such sanity checks were
>> modified
>> as proposed, has lead me to thinking that these changes would be
>> benefitial. I haven't observed any undesirable side effects (meaning,
>> nothing seems to have blown up :)). However, I'm inexperienced in
>> working
>> with the VM, so it's rather expectable that I miss something :) Your
>> input
>> on the topic would be extremely appreciated.
>>
>> The attached changesets contain the proposed set of changes.
>>
>> Cheers!
>>
>> -Laura Perez Cerrato
>>
>>
>
>

> --
> _,,,^..^,,,_
> best, Eliot
>