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
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 < lauraperezcerrato@gmail.com> 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
Sure
Sent from my iPhone
On Jun 15, 2016, at 9:37 AM, Eliot Miranda eliot.miranda@gmail.com wrote:
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 lauraperezcerrato@gmail.com 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
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 < lauraperezcerrato@gmail.com> 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
Thanks to you all :) Should I commit those?
-Laura Perez Cerrato
On 15 June 2016 at 15:56, David T. Lewis lewis@mail.msen.com wrote:
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 < lauraperezcerrato@gmail.com> 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
On Wed, Jun 15, 2016 at 11:57 AM, Laura Perez Cerrato < lauraperezcerrato@gmail.com> wrote:
Thanks to you all :) Should I commit those?
I did already I think. But next time it'll be up to you ;-)
-Laura Perez Cerrato
On 15 June 2016 at 15:56, David T. Lewis lewis@mail.msen.com wrote:
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 < lauraperezcerrato@gmail.com> 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
vm-dev@lists.squeakfoundation.org
-
David T. Lewis -
Eliot Miranda -
John McIntosh -
Laura Perez Cerrato