Opened 9 years ago

Last modified 6 years ago

#11858 new defect

Animated smilies display at different speeds

Reported by: Alien Heads Owned by: datallah
Milestone: Component: winpidgin (gtk)
Version: 2.7.0 Keywords:
Cc: oldbushie

Description

Since updating from 2.6.6 to 2.7.0 animated custom smilies that worked fine in 2.6.6 now run either too slow or too fast both in the smilies preview selection box & when used.

Windows XP Pro SP3

Attachments (1)

test.cc (1.8 KB) - added by SgtPepper 8 years ago.
Example GIF renderer to simplify debugging.

Download all attachments as: .zip

Change History (28)

comment:1 Changed 9 years ago by darkrain42

  • Component changed from unclassified to pidgin (gtk)
  • Owner changed from rekkanoryo to datallah

I wonder if this is an issue with the newer GTK+?

comment:2 follow-up: Changed 9 years ago by datallah

  • Component changed from pidgin (gtk) to winpidgin (gtk)

Presumably it is related to GTK+ since we don't render those ourselves.

There isn't a lot we can do about this.

I believe that the GTK+ version in use now uses the built-in Windows image processing functionality to do the rendering.

comment:3 in reply to: ↑ 2 Changed 9 years ago by Alien Heads

Replying to datallah:

Presumably it is related to GTK+ since we don't render those ourselves.

There isn't a lot we can do about this.

I believe that the GTK+ version in use now uses the built-in Windows image processing functionality to do the rendering.

It is rather annoying is there any way of using the old GTK+ with the new Pidgin 2.7.0?

comment:4 follow-up: Changed 9 years ago by datallah

  • Status changed from new to pending

Yes, it is possible to use GTK+ 2.14.7 with Pidgin 2.7.0.

You can download the 2.14.7 runtime zip file from here and replace your <Pidgin Installation Directory>\Gtk directory with the contents of that zip file.

comment:5 in reply to: ↑ 4 Changed 9 years ago by Alien Heads

  • Status changed from pending to new

Replying to datallah:

Yes, it is possible to use GTK+ 2.14.7 with Pidgin 2.7.0.

You can download the 2.14.7 runtime zip file from here and replace your <Pidgin Installation Directory>\Gtk directory with the contents of that zip file.


Thank you for that, is that the one used for Pidgin 2.6.6?

comment:6 follow-up: Changed 9 years ago by datallah

Yes, Pidgin 2.6.6 used GTK+ 2.14.7.

comment:7 in reply to: ↑ 6 Changed 9 years ago by Alien Heads

Replying to datallah:

Yes, Pidgin 2.6.6 used GTK+ 2.14.7.


Yes it is definitely the new version of GTK+ that is having adverse affects on the animated custom smilies.

I have installed Pidgin 2.7.1devel (libpurple 2.7.0) from http://sourceforge.net/projects/pidgin/files/Pidgin/pidgin-2.7.0.exe along with the GTK+ that comes with it & the smilies still run at different speeds, some too slow some too fast.

But when i installed the previous version of GTK+ that you posted above the smilies work as they should.

Is this worth reporting to GTK+ (or whoever it may concern)?

Thank you for your help.

comment:8 Changed 9 years ago by dbeusee

I installed gimp (http://prdownloads.sourceforge.net/gimp-win/gtk+-2.8.18-setup-1.zip?download) which uses the same version of GTK+ as pidign 2.7, and it works just fine.

Open any gif in this program, then go to filter -> animated -> playback...

This playback program actually does better than pidgin ever did (it is in fact exactly like the browser (IE) and like yahoo messenger). Pidgin has always been too fast compared to yahoo messenger. I use the same gif files provided in yahoo messenger and pidgin has always rendered them a little fast (but in 2.7 it became much worse).

Why is gimp able to render it correctly with the same version of GTK?

comment:9 follow-up: Changed 9 years ago by datallah

I believe that GIMP doesn't use the built-in GTK+ stuff for rendering graphics.

comment:10 in reply to: ↑ 9 Changed 9 years ago by Alien Heads

Replying to datallah:

I believe that GIMP doesn't use the built-in GTK+ stuff for rendering graphics.


So what is causing this problem then GTK+ or Pidgin because everything ran fine on 2.6.6 & the GTK+ version that came with it.

It spoils what was a very good feature. For new users who have never used pidgin before might be put off by custom smilies that don't render properly, i know i would be.

Can't grumble though, after all it is a free program & other than the odd glitch here & there a good one.

comment:11 Changed 9 years ago by dbeusee

datallah, are you sure gump animation player doesn't use GTK? I see a reference to the GTK .dll in animation-play.exe - it would be silly for it to not use it's own API. Maybe you should take a look at the source code for this and see how this program does it.

Can you should file a GTK/GDK bug? I think you should do it, since I'm sure there will be some back and forth about the API calls you are making, parameters, etc, and put a URL to the bug here so we can all see the progress.

comment:12 Changed 9 years ago by darkrain42

Ticket #12018 has been marked as a duplicate of this ticket.

comment:13 Changed 9 years ago by darkrain42

Ticket #12274 has been marked as a duplicate of this ticket.

comment:14 Changed 8 years ago by datallah

Ticket #12849 has been marked as a duplicate of this ticket.

comment:15 Changed 8 years ago by me_pollack

So is there a fix?

Still happening even though I replace the gdk

comment:16 Changed 8 years ago by me_pollack

Running 2.7.10 and it is still happening If I change the gdk to an older one the encryption stops working

Is there a fix for this yet?

comment:17 Changed 8 years ago by SgtPepper

I finally got sick of this today and dove into the code to find the problem, and I think I've root-caused this issue.

Between the 2.16.6-20091215 and 2.16.6-20100207 release of the gtk+-bundle for win32 (prepackaged bundle of GTK+ and relevant dependencies), they began linking in GDI+ for rendering of certain image formats. Based on my observations, I assume Pidgin is using some form of this bundle distribution.

However, it looks like there is a bug in the gdk-pixbuf code for handling gdip-managed images. In gdip_bitmap_get_frame_delay@…, the code fetches an array of delay values but only ever uses the first number!

item->value is a pointer to an array of values, which you'd use the frame number index into. But, it's just dereferencing the base address (always frame 1).

*delay = *((long *)item->value);

should be

/* would need to look into how to get frame_number from GDI+ API */
*delay = ((long *)item->value)[frame_number];  

There's a few ways this could be fixed.

  1. Build gdk-pixbuf with -DINCLUDE_gif, which would include native GIF handling and would be used in preference to GDI+.
  2. Build gdk-pixbuf without GDI+, then GIF handling would default to GModule dynamic module loading, which is what it was before.
  3. Fix the bug in gdk-pixbuf's GDI+ handling for frame delays.

The last option is obviously gdk-pixbuf's responsibility, but I believe it would be possible to fix this in Pidgin using option 1 or 2 without having to rely on gdk-pixbuf getting a fix (and upgrading Pidgin to using a bleeding edge gtk-bundle).

I created a quick sample program that illustrates the problem (attached). When linked against gtk-bundle 2.16.6-20091215, the animation renders correctly. When linked against gtk-bundle 2.16.6-20100207, I confirmed that all frames are rendered with the first frame's delay! If anyone else wants to run the test program, you can rename any variable-delay GIF as test.gif in the working directory. I used http://l.yimg.com/us.yimg.com/i/mesg/emoticons7/6.gif (Yahoo!IM's "bighug"), but I won't attach it since I'm uncertain of what the copyright issues would be. It has a frame delay of 1 second for the first frame and .1 seconds for most of the other frames.

I will look into filing a bug against gdk-pixbuf, but I don't really want to figure out how to compile GTK+/gdk-pixbuf. So, I probably won't be submitting a patch (since I couldn't confirm it without compiling), even though I think I've come up with the proper code fix.

Changed 8 years ago by SgtPepper

Example GIF renderer to simplify debugging.

comment:18 Changed 8 years ago by SgtPepper

Whoops. I figured when the comment box says "you may use WikiFormatting", it would understand MediaWiki?'s auto-numbered lists).

Here are the options I mentioned with better formatting:

  1. Build gdk-pixbuf with -DINCLUDE_gif, which would include native GIF handling and would be used in preference to GDI+.
  2. Build gdk-pixbuf without GDI+, then GIF handling would default to GModule dynamic module loading. This is how it was before the gtk-bundle change.
  3. Fix the bug in gdk-pixbuf's GDI+ handling for frame delays.

comment:19 Changed 8 years ago by SgtPepper

I want to reiterate, though, that this could be fixed on Pidgin's end by distributing a GTK package that's compiled with slightly different options.

comment:20 Changed 8 years ago by SgtPepper

Submitted to Gnome as Bug 655755 (https://bugzilla.gnome.org/show_bug.cgi?id=655755)

comment:21 Changed 8 years ago by datallah

Good job digging in and figuring out what the cause of the issue is.

We've historically avoided compiling GTK+ ourselves, so it would be ideal if option 3 would happen. That said, we aren't using the latest GTK+ version (even in the 2.x.y series) because of some known issues with newer versions, so even if it were fixed upstream, that wouldn't offer an immediate fix to the problem.

I think the ideal solution would be to get it fixed upsteam in a 2.x.y GTK+ release and then for us to be able to upgrade to that release (basically to test and make sure there aren't any significant regressions). Unfortunately, I don't have any time in my schedule to dedicate to that at the moment, so hopefully someone else can work to make that happen.

comment:22 Changed 8 years ago by SgtPepper

What about releasing with gtk-bundle 2.16.6-20091215 (last gtk-bundle that didn't use GDI+ for GIF parsing) until it gets fixed upstream (and upstream becomes compatible with Pidgin)? Is there anything in the later 2.16.6 releases that Pidgin relies on (or important security fixes)?

comment:23 Changed 8 years ago by SgtPepper

@datallah,

Since I see you've CCed yourself to the Gnome bug, you probably have seen that I went ahead and provided a patch. In order to test it, I not only used my test program, but I also dropped in an updated libgdk_pixbuf-2.0-0.dll and libglib-2.0-0.dll (the version of pixbuf I compiled required a newer glib) into my Pidgin/Gtk?/bin directory. I've confirmed that this completely fixes the issue for me.

If downgrading or upgrading the entire gtk-bundle to a working version is undesirable, I could provide these two DLLs (or simple instructions on how to configure/build them) and they could be put in the current bundle for distribution. I could also go back and patch an older gdk-pixbuf if the newer glib is an issue.

comment:24 follow-up: Changed 8 years ago by me_pollack

The only issue I have seen by using the older GDK is that the encryption extension did not work.

The encryption extension is one of top reasons I have been getting the businesses to use Pidgin as its official client.

comment:25 in reply to: ↑ 24 Changed 8 years ago by me_pollack

oops - GTK

comment:26 Changed 7 years ago by SgtPepper

The Gnome bug was resolved a few months ago and was just included in a release (gdk-pixbuf 2.25.0).

comment:27 Changed 6 years ago by Zenit

Im using 2.10.7 and smileys still lag :(

Note: See TracTickets for help on using tickets.
All information, including names and email addresses, entered onto this website or sent to mailing lists affiliated with this website will be public. Do not post confidential information, especially passwords!