[jitsi-dev] Animated GIFs


#1

Here's a funny one. Try pasting this link, http://mecdude7.net/inet/emot/MacNerdClap.gif, into a Jitsi XMPP chat window. The GIF plays at the right speed the first time through but after that, it runs waaaaay too fast. Looks pretty funny :slight_smile: I'm able to reproduce this with other animated GIFs.

I'm using Windows 7 64-bit and 1.0-beta1-nightly.build.3903. Though, I've also reproduced the behavior on 3820 (last stable build).

Aaron


#2

Hey Aaron,

Could you please open an issue?

Thanks,
Emil

路路路

On 15.02.12 22:20, Aaron Stover (Celestech) wrote:

Here's a funny one. Try pasting this link,
http://mecdude7.net/inet/emot/MacNerdClap.gif, into a Jitsi XMPP chat
window. The GIF plays at the right speed the first time through but
after that, it runs waaaaay too fast. Looks pretty funny :slight_smile: I'm able to
reproduce this with other animated GIFs.

I'm using Windows 7 64-bit and 1.0-beta1-nightly.build.3903. Though,
I've also reproduced the behavior on 3820 (last stable build).

Aaron

--
Emil Ivov, Ph.D. 67000 Strasbourg,
Project Lead France
Jitsi
emcho@jitsi.org PHONE: +33.1.77.62.43.30
http://jitsi.org FAX: +33.1.77.62.47.31


#3

The problem is the gif itself:
the delay time between frames is 0 millisec!

from what I know, java-swing suffers in this condition with the cpu goes at 100%

Have you noticed this problem?

regards
davide

路路路

Il 15/02/2012 22.20, Aaron Stover (Celestech) ha scritto:

Here's a funny one. Try pasting this link, http://mecdude7.net/inet/emot/MacNerdClap.gif, into a Jitsi XMPP chat window. The GIF plays at the right speed the first time through but after that, it runs waaaaay too fast. Looks pretty funny :slight_smile: I'm able to reproduce this with other animated GIFs.

I'm using Windows 7 64-bit and 1.0-beta1-nightly.build.3903. Though, I've also reproduced the behavior on 3820 (last stable build).

Aaron

-----
Nessun virus nel messaggio.
Controllato da AVG - www.avg.com
Versione: 2012.0.1913 / Database dei virus: 2112/4811 - Data di rilascio: 15/02/2012


#4

Didn't notice the 0ms delay, nice catch. Though it's still odd that it plays at a speed similar to what I see in Firefox the first time through. Maybe it's just an artifact of loading each frame?

You're also correct that it sucks up an enormous amount of CPU. Even worse, it doesn't stop when the chat window is closed. The only way I could figure out to stop it was to restart Jitsi. And even then, if you open a chat with the same person, the GIF loads up again and starts sucking up cycles. So really, to fix it you've got to quite JItsi, delete the history for that contact, and then start Jitsi again.

So Firefox must have a default delay value that it uses when it encounters a GIF with 0ms specified as the delay. So really, this isn't a bug with Jitsi; it's just following directions. Maybe a default delay value could be implemented as an enhancement?

Thanks,
Aaron

路路路

On 2/16/2012 2:06 AM, Davide Corda wrote:

The problem is the gif itself:
the delay time between frames is 0 millisec!

from what I know, java-swing suffers in this condition with the cpu goes at 100%

Have you noticed this problem?

regards
davide

Il 15/02/2012 22.20, Aaron Stover (Celestech) ha scritto:

Here's a funny one. Try pasting this link, http://mecdude7.net/inet/emot/MacNerdClap.gif, into a Jitsi XMPP chat window. The GIF plays at the right speed the first time through but after that, it runs waaaaay too fast. Looks pretty funny :slight_smile: I'm able to reproduce this with other animated GIFs.

I'm using Windows 7 64-bit and 1.0-beta1-nightly.build.3903. Though, I've also reproduced the behavior on 3820 (last stable build).

Aaron

-----
Nessun virus nel messaggio.
Controllato da AVG - www.avg.com
Versione: 2012.0.1913 / Database dei virus: 2112/4811 - Data di rilascio: 15/02/2012


#5

Hey Aaron,

Didn't notice the 0ms delay, nice catch. Though it's still odd that it
plays at a speed similar to what I see in Firefox the first time
through. Maybe it's just an artifact of loading each frame?

You're also correct that it sucks up an enormous amount of CPU. Even
worse, it doesn't stop when the chat window is closed. The only way I
could figure out to stop it was to restart Jitsi. And even then, if you
open a chat with the same person, the GIF loads up again and starts
sucking up cycles. So really, to fix it you've got to quite JItsi,
delete the history for that contact, and then start Jitsi again.

So Firefox must have a default delay value that it uses when it
encounters a GIF with 0ms specified as the delay. So really, this isn't
a bug with Jitsi; it's just following directions. Maybe a default delay
value could be implemented as an enhancement?

That would be awesome indeed. We don't currently have the time to look
into this so if you find an easy way of doing it, we'd be very grateful
for a patch!

Cheers,
Emil

路路路

On 19.02.12 04:09, Aaron Stover (Celestech) wrote:

Thanks,
Aaron

On 2/16/2012 2:06 AM, Davide Corda wrote:

The problem is the gif itself:
the delay time between frames is 0 millisec!

from what I know, java-swing suffers in this condition with the cpu
goes at 100%

Have you noticed this problem?

regards
davide

Il 15/02/2012 22.20, Aaron Stover (Celestech) ha scritto:

Here's a funny one. Try pasting this link,
http://mecdude7.net/inet/emot/MacNerdClap.gif, into a Jitsi XMPP chat
window. The GIF plays at the right speed the first time through but
after that, it runs waaaaay too fast. Looks pretty funny :slight_smile: I'm able
to reproduce this with other animated GIFs.

I'm using Windows 7 64-bit and 1.0-beta1-nightly.build.3903. Though,
I've also reproduced the behavior on 3820 (last stable build).

Aaron

-----
Nessun virus nel messaggio.
Controllato da AVG - www.avg.com
Versione: 2012.0.1913 / Database dei virus: 2112/4811 - Data di
rilascio: 15/02/2012

--
Emil Ivov, Ph.D. 67000 Strasbourg,
Project Lead France
Jitsi
emcho@jitsi.org PHONE: +33.1.77.62.43.30
http://jitsi.org FAX: +33.1.77.62.47.31


#6

I think the problem is the HTML processor in java.
If you use a JLabel, probably, there is a trick overriding Update method and so on
(someone on internet suggested this solution)

But in our case (chat panel), we have an html tagobtained from
ReplacementServiceDirectImageImpl.java

I suggest to change the pattern removing the "gif" match

(line 30 of net.java.sip.communicator.impl.replacement.directimage/ReplacementServiceDirectImageImpl.java)

regards
davide

路路路

Il 21/02/2012 9.06, Emil Ivov ha scritto:

Hey Aaron,

On 19.02.12 04:09, Aaron Stover (Celestech) wrote:

Didn't notice the 0ms delay, nice catch. Though it's still odd that it
plays at a speed similar to what I see in Firefox the first time
through. Maybe it's just an artifact of loading each frame?

You're also correct that it sucks up an enormous amount of CPU. Even
worse, it doesn't stop when the chat window is closed. The only way I
could figure out to stop it was to restart Jitsi. And even then, if you
open a chat with the same person, the GIF loads up again and starts
sucking up cycles. So really, to fix it you've got to quite JItsi,
delete the history for that contact, and then start Jitsi again.

So Firefox must have a default delay value that it uses when it
encounters a GIF with 0ms specified as the delay. So really, this isn't
a bug with Jitsi; it's just following directions. Maybe a default delay
value could be implemented as an enhancement?

That would be awesome indeed. We don't currently have the time to look
into this so if you find an easy way of doing it, we'd be very grateful
for a patch!

Cheers,
Emil

Thanks,
Aaron

On 2/16/2012 2:06 AM, Davide Corda wrote:

The problem is the gif itself:
the delay time between frames is 0 millisec!

from what I know, java-swing suffers in this condition with the cpu
goes at 100%

Have you noticed this problem?

regards
davide

Il 15/02/2012 22.20, Aaron Stover (Celestech) ha scritto:

Here's a funny one. Try pasting this link,
http://mecdude7.net/inet/emot/MacNerdClap.gif, into a Jitsi XMPP chat
window. The GIF plays at the right speed the first time through but
after that, it runs waaaaay too fast. Looks pretty funny :slight_smile: I'm able
to reproduce this with other animated GIFs.

I'm using Windows 7 64-bit and 1.0-beta1-nightly.build.3903. Though,
I've also reproduced the behavior on 3820 (last stable build).

Aaron

-----
Nessun virus nel messaggio.
Controllato da AVG - www.avg.com
Versione: 2012.0.1913 / Database dei virus: 2112/4811 - Data di
rilascio: 15/02/2012


#7

Well, ideally we should be able to fix this without losing functionality.
No ideas in that direction? Anyone?

Emil

-- sent from my mobile

路路路

On Feb 21, 2012 7:36 PM, "Davide Corda" <davide.corda@abbeynet.it> wrote:

I think the problem is the HTML processor in java.
If you use a JLabel, probably, there is a trick overriding Update method
and so on
(someone on internet suggested this solution)

But in our case (chat panel), we have an html tagobtained from
ReplacementServiceDirectImageI**mpl.java

I suggest to change the pattern removing the "gif" match

(line 30 of net.java.sip.communicator.**impl.replacement.directimage/**
ReplacementServiceDirectImageI**mpl.java)

regards
davide

Il 21/02/2012 9.06, Emil Ivov ha scritto:

Hey Aaron,

On 19.02.12 04:09, Aaron Stover (Celestech) wrote:

Didn't notice the 0ms delay, nice catch. Though it's still odd that it
plays at a speed similar to what I see in Firefox the first time
through. Maybe it's just an artifact of loading each frame?

You're also correct that it sucks up an enormous amount of CPU. Even
worse, it doesn't stop when the chat window is closed. The only way I
could figure out to stop it was to restart Jitsi. And even then, if you
open a chat with the same person, the GIF loads up again and starts
sucking up cycles. So really, to fix it you've got to quite JItsi,
delete the history for that contact, and then start Jitsi again.

So Firefox must have a default delay value that it uses when it
encounters a GIF with 0ms specified as the delay. So really, this isn't
a bug with Jitsi; it's just following directions. Maybe a default delay
value could be implemented as an enhancement?

That would be awesome indeed. We don't currently have the time to look
into this so if you find an easy way of doing it, we'd be very grateful
for a patch!

Cheers,
Emil

Thanks,

Aaron

On 2/16/2012 2:06 AM, Davide Corda wrote:

The problem is the gif itself:
the delay time between frames is 0 millisec!

from what I know, java-swing suffers in this condition with the cpu
goes at 100%

Have you noticed this problem?

regards
davide

Il 15/02/2012 22.20, Aaron Stover (Celestech) ha scritto:

Here's a funny one. Try pasting this link,
http://mecdude7.net/inet/emot/**MacNerdClap.gif<http://mecdude7.net/inet/emot/MacNerdClap.gif>,
into a Jitsi XMPP chat
window. The GIF plays at the right speed the first time through but
after that, it runs waaaaay too fast. Looks pretty funny :slight_smile: I'm able
to reproduce this with other animated GIFs.

I'm using Windows 7 64-bit and 1.0-beta1-nightly.build.3903. Though,
I've also reproduced the behavior on 3820 (last stable build).

Aaron

-----
Nessun virus nel messaggio.
Controllato da AVG - www.avg.com
Versione: 2012.0.1913 / Database dei virus: 2112/4811 - Data di
rilascio: 15/02/2012


#8

starting from reported bug
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4821632

we have built our class ImageView with suitable
hacks in the ImageHandler.imageUpdate function, so that
continuous loops (and CPU consumption) caused by animated gif with zero inter-frame delay
can be dealt with.

We have added this code in
public View create(Element elem)
function, line 58 of
src\net\java\sip\communicator\util\swing\SIPCommHTMLEditorKit.java

聽聽聽聽聽聽聽聽聽聽聽聽聽Object o =
聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽elem.getAttributes().getAttribute(StyleConstants.NameAttribute);
聽聽聽聽聽聽聽聽聽聽聽聽聽if (o instanceof HTML.Tag) {
聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽HTML.Tag kind = (HTML.Tag) o;
聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽if (kind == HTML.Tag.IMG){
聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽return new MyImageView(elem);
聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽}
聽聽聽聽聽聽聽聽聽聽聽聽聽}

In the attachment you can find the class, that has been modified starting from the original
sun-oracle
to be copied into src\net\java\sip\communicator\util\swing\

regards,

Davide

MyImageView.zip (8.45 KB)

路路路

Il 22/02/2012 9.05, Emil Ivov ha scritto:

Well, ideally we should be able to fix this without losing functionality. No ideas in that direction? Anyone?

Emil

-- sent from my mobile

On Feb 21, 2012 7:36 PM, "Davide Corda" <davide.corda@abbeynet.it > <mailto:davide.corda@abbeynet.it>> wrote:

聽聽聽聽I think the problem is the HTML processor in java.
聽聽聽聽If you use a JLabel, probably, there is a trick overriding Update
聽聽聽聽method and so on
聽聽聽聽(someone on internet suggested this solution)

聽聽聽聽But in our case (chat panel), we have an html tagobtained from
聽聽聽聽ReplacementServiceDirectImageImpl.java

聽聽聽聽I suggest to change the pattern removing the "gif" match

聽聽聽聽(line 30 of
聽聽聽聽net.java.sip.communicator.impl.replacement.directimage/ReplacementServiceDirectImageImpl.java)

聽聽聽聽regards
聽聽聽聽davide

聽聽聽聽Il 21/02/2012 9.06, Emil Ivov ha scritto:

聽聽聽聽聽聽聽聽Hey Aaron,

聽聽聽聽聽聽聽聽On 19.02.12 04:09, Aaron Stover (Celestech) wrote:

聽聽聽聽聽聽聽聽聽聽聽聽Didn't notice the 0ms delay, nice catch. Though it's still
聽聽聽聽聽聽聽聽聽聽聽聽odd that it
聽聽聽聽聽聽聽聽聽聽聽聽plays at a speed similar to what I see in Firefox the
聽聽聽聽聽聽聽聽聽聽聽聽first time
聽聽聽聽聽聽聽聽聽聽聽聽through. Maybe it's just an artifact of loading each frame?

聽聽聽聽聽聽聽聽聽聽聽聽You're also correct that it sucks up an enormous amount of
聽聽聽聽聽聽聽聽聽聽聽聽CPU. Even
聽聽聽聽聽聽聽聽聽聽聽聽worse, it doesn't stop when the chat window is closed. The
聽聽聽聽聽聽聽聽聽聽聽聽only way I
聽聽聽聽聽聽聽聽聽聽聽聽could figure out to stop it was to restart Jitsi. And even
聽聽聽聽聽聽聽聽聽聽聽聽then, if you
聽聽聽聽聽聽聽聽聽聽聽聽open a chat with the same person, the GIF loads up again
聽聽聽聽聽聽聽聽聽聽聽聽and starts
聽聽聽聽聽聽聽聽聽聽聽聽sucking up cycles. So really, to fix it you've got to
聽聽聽聽聽聽聽聽聽聽聽聽quite JItsi,
聽聽聽聽聽聽聽聽聽聽聽聽delete the history for that contact, and then start Jitsi
聽聽聽聽聽聽聽聽聽聽聽聽again.

聽聽聽聽聽聽聽聽聽聽聽聽So Firefox must have a default delay value that it uses
聽聽聽聽聽聽聽聽聽聽聽聽when it
聽聽聽聽聽聽聽聽聽聽聽聽encounters a GIF with 0ms specified as the delay. So
聽聽聽聽聽聽聽聽聽聽聽聽really, this isn't
聽聽聽聽聽聽聽聽聽聽聽聽a bug with Jitsi; it's just following directions. Maybe a
聽聽聽聽聽聽聽聽聽聽聽聽default delay
聽聽聽聽聽聽聽聽聽聽聽聽value could be implemented as an enhancement?

聽聽聽聽聽聽聽聽That would be awesome indeed. We don't currently have the time
聽聽聽聽聽聽聽聽to look
聽聽聽聽聽聽聽聽into this so if you find an easy way of doing it, we'd be very
聽聽聽聽聽聽聽聽grateful
聽聽聽聽聽聽聽聽for a patch!

聽聽聽聽聽聽聽聽Cheers,
聽聽聽聽聽聽聽聽Emil

聽聽聽聽聽聽聽聽聽聽聽聽Thanks,
聽聽聽聽聽聽聽聽聽聽聽聽Aaron

聽聽聽聽聽聽聽聽聽聽聽聽On 2/16/2012 2:06 AM, Davide Corda wrote:

聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽The problem is the gif itself:
聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽the delay time between frames is 0 millisec!

聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽from what I know, java-swing suffers in this condition
聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽with the cpu
聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽goes at 100%

聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽Have you noticed this problem?

聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽regards
聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽davide

聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽Il 15/02/2012 22.20, Aaron Stover (Celestech) ha scritto:

聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽Here's a funny one. Try pasting this link,
聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽http://mecdude7.net/inet/emot/MacNerdClap.gif,
聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽into a Jitsi XMPP chat
聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽window. The GIF plays at the right speed the first
聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽time through but
聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽after that, it runs waaaaay too fast. Looks pretty
聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽funny :slight_smile: I'm able
聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽to reproduce this with other animated GIFs.

聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽I'm using Windows 7 64-bit and
聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽1.0-beta1-nightly.build.3903 <tel:3903>. Though,
聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽I've also reproduced the behavior on 3820
聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽<tel:3820> (last stable build).

聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽Aaron

聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽-----
聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽Nessun virus nel messaggio.
聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽Controllato da AVG - www.avg.com <http://www.avg.com>
聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽Versione: 2012.0.1913 / Database dei virus:
聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽2112/4811 - Data di
聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽rilascio: 15/02/2012

Nessun virus nel messaggio.
Controllato da AVG - www.avg.com <http://www.avg.com>
Versione: 2012.0.1913 / Database dei virus: 2113/4823 - Data di rilascio: 21/02/2012