Re: master 8b7aaf3e56: Speed up GIF animations

Re: master 8b7aaf3e56: Speed up GIF animations

[Po Lu]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> +  int cache_image_size = width * height * ximg->bits_per_pixel / 8;

Emacs_Pix_Container is an opaque type that can be typedefed to a variety
of things on different platforms.

You cannot directly refer to bits_per_pixel, which only exists on X.
This will probably break if bits_per_pixel is not a multiple of 8 as
well.  It can be any random value on X Windows, and might not even exist
if the image format is not ZPixmap.

What is the temp field for?  Is it for storing bitmap data?  If so, it
should just be a bitmap set using the PUT_PIXEL macro.

Re: master 8b7aaf3e56: Speed up GIF animations

[Lars Ingebrigtsen]

Po Lu <luangruo@yahoo.com> writes:

>> +  int cache_image_size = width * height * ximg->bits_per_pixel / 8;
>
> Emacs_Pix_Container is an opaque type that can be typedefed to a variety
> of things on different platforms.
>
> You cannot directly refer to bits_per_pixel, which only exists on X.
> This will probably break if bits_per_pixel is not a multiple of 8 as
> well.  It can be any random value on X Windows, and might not even exist
> if the image format is not ZPixmap.

Right.

> What is the temp field for?  Is it for storing bitmap data?  If so, it
> should just be a bitmap set using the PUT_PIXEL macro.

I want to copy the bitmap that we've already computed in an efficient
way.  PUT_PIXEL would be way too slow.  Any ideas?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: master 8b7aaf3e56: Speed up GIF animations

[Lars Ingebrigtsen]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> I want to copy the bitmap that we've already computed in an efficient
> way.  PUT_PIXEL would be way too slow.  Any ideas?

Perhaps it makes more sense to reverse the direction here.  That is,
have load_gif only work on an area it allocates itself, and cache that.
And then use PUT_PIXEL at the end to copy to the ximg...  That should be
portable, I think, without knowing anything about what the ximg really
is.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: master 8b7aaf3e56: Speed up GIF animations

[Lars Ingebrigtsen]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Perhaps it makes more sense to reverse the direction here.  That is,
> have load_gif only work on an area it allocates itself, and cache that.
> And then use PUT_PIXEL at the end to copy to the ximg...  That should be
> portable, I think, without knowing anything about what the ximg really
> is.

Yes, that seems to work well, and makes gif_load a bit faster to boot.
I have to run some errands now, but I'll fix it up later today and push
it.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: master 8b7aaf3e56: Speed up GIF animations

[Lars Ingebrigtsen]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Yes, that seems to work well, and makes gif_load a bit faster to boot.
> I have to run some errands now, but I'll fix it up later today and push
> it.

Now pushed.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: master 8b7aaf3e56: Speed up GIF animations

[Po Lu]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Lars Ingebrigtsen <larsi@gnus.org> writes:
>
>> Yes, that seems to work well, and makes gif_load a bit faster to boot.
>> I have to run some errands now, but I'll fix it up later today and push
>> it.
>
> Now pushed.

Thanks.

Re: master 8b7aaf3e56: Speed up GIF animations

[Po Lu]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> I want to copy the bitmap that we've already computed in an efficient
> way.  PUT_PIXEL would be way too slow.

Not that I know of.  But I suspect that this doesn't really matter since
gif_load is only called once when loading an image into the image cache.

Using memcpy cannot possibly be correct with X images either.  What if
the X server demands the image be byteswapped, has odd padding
requirements, doesn't have a concept of "bits per pixel" and/or "bytes
per pixel", or has different masks for various components of a ZPixmap?

The only reliable way to deal with that mess is to use XPutPixel or
XGetPixel.  (Which image.c abstracts away with the PUT_PIXEL and
GET_PIXEL macros.)