Closed Bug 219625 Opened 19 years ago Closed 18 years ago

When compiled with GTK2 flash (macromedia) movies are very slow.

Categories

(Core Graveyard :: Plug-ins, defect)

x86
Linux
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: pasrospa, Assigned: peterlubczynski-bugs)

References

()

Details

Attachments

(4 files)

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5a) Gecko/20030918 Mozilla Firebird/0.6.1
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5a) Gecko/20030918 Mozilla Firebird/0.6.1

When compiled with GTK2 flash movies are very slow, this doesnt happen when
compiled without it.

Reproducible: Always

Steps to Reproduce:
1.Compile with GTK2 support
2.Install macromedia flash plugin
3.

Actual Results:  
Slow flash animations.

Expected Results:  
Show them at normal speed.
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030920

confirm this on mozilla compiled with gtk2 (and epiphany, too). The movie is
played slower.
And also, there's unwanted left and top border on the flash movie. (.png attached)
Attached image .png
Attached image mozilla2.png
is it just the fact that you compile with gtk2? what system do you use?? I got
the same bug with the official 0.7 Mozillafirebird release under Mandrake but it
does not affect red hat 9.0.
*** Bug 222311 has been marked as a duplicate of this bug. ***
Blocks: 222311
No longer blocks: 222311
Yes, i'm pretty sure it's because of gtk2.
I pulled mozilla firebird cvs on 20031017 and compiled it without gtk2 and flash
works fine.
Btw, mozilla 1.5 has this problem, too.

My system: Ahtlon-XP 2100+, 512 MB DDR on Gentoo Linux
what version of the flash plugin?
I had this problem (http://bugzilla.mozilla.org/show_bug.cgi?id=222311) 
Flash was slow with gtk2/xft and ok with gtk1
But by upgrading the plugin to 6.79 it is now all fine
can u about:plugins and check your flash version?
    File name: libflashplayer.so
    Shockwave Flash 6.0 r79
heh.. yeah.. forgot to tell my flash version:
    File name: libflashplayer.so
    Shockwave Flash 6.0 r79

(same as yours)
weird, u sure u compiled ur mozilla with gtk2 support?
did you see the left and top-border on flash movies?
This problem does NOT have to do with the flash version.  It has to do with the
combination of GTK2 and XFT, and it does not show up in all systems.  I'm using
the latest flash plugin (6.0 r79) with mozilla 1.5 and firebird .7 on Slackware
9.1 - flash remains slow and the unwanted 1px border is always there. Switching
a gtk1 version fixes it.

NOTE - I have observed this same problem using Galleon with Gnome 2.4 on
Slackware and the 6.0 r79 plugin, so it's not limited to Mozilla.
It is not necessary to have flash installed to observe the problem (the 1px
lines give it away).
Picture taken from Mozilla 1.5 xft/gtk2: the 1px black line on the top and left
of the flash area reveal the bug without flash installed.
Attached image No problem here.
With gtk1, no 1px black lines (everything is peachy).

NOTE - this two attachments are taken from identical builds except for
--enable-default-toolkit (gtk vs gtk2)
Well I have gtk2/xft firebird and flash works.. at least it is not slow.
The only problem I have with flash is with the salign stuff
http://bugzilla.mozilla.org/show_bug.cgi?id=222581
Maybe there is a difference between flash versions u get in .tgz and in .rpm
File name: libflashplayer.so
Shockwave Flash 6.0 r79

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031007 Firebird/0.7

Slackware 9.1 PIII/733MHz

I've been having the same problems with both Mozilla and Firebird. Both are
built with GTK2 and XFT support. 
Some--if not most--Flash sites freeze up Firebird 0.7 on my machine (Slackware
9.1) -- whether compiled with gtk2/xft or gtk1.2. This used to happen with
Slackware 7.1 and is/was one of the chief reasons that I decided to upgrade.
This site  www.morgandetoi.com chokes bad, freezes my desktop, preventing me
from opening up a termianl to kill off firebird.

Oh yeah: the flash version is 6.0 r79 and java is 1.4.2_01-b06.

Frustrated!
This may a build issue with Flash.  I was running Flash version 6.0 r79 that I
had downloaded in a .tar.gz file.  Several Flash applications seemed to run
slowly for me (including
http://www.princeofpersiagame.com/minigame/game/flash/index.html).  I went just
now to the Flash download site and found an RPM specific to RedHat 9.0.  Once I
installed this, the application I linked too is much faster (although still
somewhat slow).  In particular, the animations seem to be running properly now.

Sadly, I did not try the URL associated with this message until after installing
the RPM so I don't know if it improves that.  Anyway, it's quite possible with
RedHat 9.0 that an application built for an earlier RedHat would behave poorly
so perhaps this is what's going on, for some people at least.  I'm using Moz 1.5
with GTK2/XFt.
Re #16: But those builds are identical!

$ tar --ungzip -xf install_flash_player_6_linux.tar.gz
$ rpm2cpio flash-plugin-6.0.79-1.i386.rpm | cpio -i -d
$ diff -s install_flash_player_6_linux/libflashplayer.so
./usr/lib/flash-plugin/libflashplayer.so
Files install_flash_player_6_linux/libflashplayer.so and
./usr/lib/flash-plugin/libflashplayer.so are identical
I recently started using Togami's linux flash-plugins from this site (
http://sluglug.ucsc.edu/macromedia/site_ucsc.html ) and in particular the one
for fedora-core-1. I did some beta testing on this, and flash looks the same to
me as it does on win32 on this setup. I don't get the funny lines on this setup
either. Does that say its something in the environment causing this in
conjunction with gtk2 builds? What else is in the environment? Only about 3
zillion gconf2 'registry' entries that I don't understand

I know the core of Togami-packaged flash plugins (the 2 *flash* files that go
into plugins) are identical although his ./setup script does do something
slightly different (like registering ~./yourfirebirddir/components/xpti.dat)
than others I've used. It registers flash as an 'xpcom' component. So that
means, I think, that these gnome (gconf-2) registry keys are added:

119,flashplayer.xpt,1,856,1046133899000
52,FlashIScriptablePlugin,{d458fe9c-518c-11d6-84cb-0005029bc257},119,-1,1
176,FlashIObject,{42b1d5a4-6c2b-11d6-8063-0005029bc257},119,-1,1
822,inIFlasher,{7b4a099f-6f6e-4565-977b-fb622adbff49},27,-1,1

Wonder if you all have those? The little bit I know about the gnome registry is
only because of searching for a couple other bugs. I don't use gnome but am
becoming uncomfortably familiar with /etc/gconf/* lol due to gtk2 builds.

inf:
Flash plugin:
http://sluglug.ucsc.edu/macromedia/apt/fedora/1/RPMS.macromedia/flash-plugin-6.0.79-2.i386.rpm
Flash install type: a scripted .rpm that registers itself with the browser (this
was broken on flash for awhile)
Distro: Fedora core 1
desktop: today, it's kde 3.1.4, often xfce
Kernel: 2.6.0-test10. (fresh off the stove), built with gcc 3.3.2-2
glibc: 2.3.2-101.1
Gecko/20031123 Firebird/0.7+ (Optimized for Athlon XP/sse by me)

When I first started running fb, ( many moons back), I thought the flash plugins
were hugely slow, and that was on a gentoo beta (and also a slackware) distro
and the flash/shock .tgz tarball from the official flash site.

Re #17: as you say, those 2 *flash* files in the ~/fb/plugins dir are identical
whether the builds be from the site I mentioned or from offical macromedia, but
would you check that other thing I mentioned about (the xpti.dat 'registered'
file in ~./fb/components)? I doubt that's actually a part of this problem, but
since I dont' have it and this is the first time I've ever seen a flash install
say "registering flash' and then leave that file there, it's a curiousity anyway. 

And for the sake of me being able to replicate this on my own gtk2 builds and in
this environment, which exact plugin (url, tarball or rpm?, version?) are you
folks having the problem using? I'll switch back to that so I can diff a few
things and see what differences it causes. 
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6b) Gecko/20031128 Firebird/0.7+

Red Hat 9.0, kernel 2.6.0-test11, glibc-2.3.2-82. Browser mentioned in UA was
compiled on a Fedora Core 1 box with gcc 3.3.2 and glibc 2.3.2-something.

Flash movies also run very slow, and have run slow under all builds I've used (I
only use GTK2+XFT builds). Under Windows XP they run at normal speed, even with
multiple Flash movies on the same page. I saw the link to the beta plugins and
will try them.
Using MEPIS 2003.10.01, flash with Mozilla and Mozilla Firebird are at normal
speeds. On the same machine using Slackware 9.1, flash is slow. 
I'm seeing bad performance on FreeBSD 5.2 with the flash plugin and Linux plugin
wrapper.  I suspect this is the same issue, although it seems to occur for me
with both gtk and gtk2.

Anyway, a good testcase to check the performance is at
http://www.weebls-stuff.com/toons/16/, which was done at a high framerate and
with smooth motion, so you can really see the difference when flash isn't
performing up to speed.

I noticed that it's consuming a small amount of CPU time compared to what it
would take to play the animation at full framerate.  What's very strange is that
if you right-click on the movie and go to settings, then select the "Local
Storage" tab (folder icon), moving the cursor around the movie area continuously
will cause the animation to run at full speed.  This only works while that
settings window is open to the Local Storage tab.  Anybody else see this weird
behavoir?
*** Bug 232079 has been marked as a duplicate of this bug. ***
(In reply to comment #21)
> if you right-click on the movie and go to settings, then select the "Local
> Storage" tab (folder icon), moving the cursor around the movie area continuously
> will cause the animation to run at full speed.  This only works while that
> settings window is open to the Local Storage tab.  Anybody else see this weird
> behavoir?
I do, I get the same results as you...

We have two computers, both P4 sonys. On both of them Flash plays fine on
Windows but on Mandrake 9.1 on one computer (2.8ghz hyper threading) it played
fine and on the other (2.4ghz) it always played slow and jerky. Recently I've
become keen on Linux from Scratch and I've just finished installing Scratch on
the old computer and I was pleased to find that Flash now plays fine. Same
Mozilla code. Same Flash plugins.
I think the issue was the chip sets the Mandrake kernel had been configured to
run on was causing problems with the way interrupts from the hard drive were
being handled, which lead to timing errors. I don't think this bug is a bug in
Mozilla code. I think it's to do with how well Linux has been set up and the
hardware it's running on. I don't think it's fixable at the level of the Mozilla
code.
I installed it on a LFS system too, but with GTK2 and IT IS jerky, the bug is
with the GTK2 frontend....
The problem with border around the plugin is bug 207036 - and it's now fixed.
Blocks: gtk2
The weird behaviour seen in comment #21 may be due to bug 124643
My Mozilla-1.6 with Gtk2/Xft had the same problem but now
it's solved.
Probably, this problem is caused by libgtk-1.2, not libgtk2
nor Mozilla.

In my case, I applied following Debian's testing patch
(ie. gtk+1.2_1.2.10-16.diff.gz) to libgtk-1.2 and re-installed
it, then the problem solved.

http://packages.debian.org/testing/libs/libgtk1.2

Also the problem can be solved by replacing from current
libgtk-1.2 to Debian's testing libgtk-1.2.

I can't understand why the problem is solved in this way.
Maybe, the flash plugin examines whether the libgtk.so
(libgtk-1.2.so) is available or not by dlopen or
something, and if it's unavailable, libgtk2 is used and it
causes extremely slow execution.
Ok, I think I found the exact cause of the problem.

Flash plugin is buggy because it always uses gtk 1.2 (checking with strace and
in strings from the plugin is quite instructive), even when mozilla is compiled
with gtk2. 

However, there is a way to tell the plugin to use gtk 2.0 instead :
export FLASH_GTK_LIBRARY=libgtk-x11-2.0.so.0

When this variable is set, flash plugin uses gtk 2.0 and the performance
problems are gone.
Is there a site with Flash ads that are known to be slow, that can be used to
test this? I added the FLASH_GTK_LIBRARY variable to the top of firefox/firefox
and restarted the program, and checked a site where I have seen slow ads before.
The ads seemed faster, but they still seemed much slower and not as smooth.

But if this is yet another deficiency in Flash, and not Mozilla's fault, does
that indicate a RESOLVED WORKSFORME?
Try http://www.bbc.co.uk/weather/

there is a small flash text animation which is deadly slow without the workaround.

I think a note should be added to release notes.
Thanks guys.

The BBCi Weather animation has sped up, but the sld.pl animation has not.

Hmmmmm.

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7b) Gecko/20040316 Firefox/0.8.0+
(daihard: XFT+GTK2; opt. for P4/SSE-2)
export FLASH_GTK_LIBRARY=libgtk-x11-2.0.so.0

This really speeds up Flash animation in GTK2 build, thanks a lot!
BTW, a new version of Linux Flash plugin is released, which is supposed to be
compiled w/ gcc 3.2, not sure how it will impact the performance:

http://videl.ics.hawaii.edu/pipermail/linuxflash/2004-March/000106.html
the game at http://meph.eu.org/ runs pretty slow when workaround w/ export lib
is not applied but when applied the animation is quite choppy.
I've installed the new flash and used the export trick and my flash at still
slow in firefox.
Re: Comment 37

When you say slow, have you compared it with gtk1.2 build of Mozilla / Firefox?
If it is also slow in gtk1.2 build, then your problem is not related to this bug
I believe.
*** Bug 240666 has been marked as a duplicate of this bug. ***
*** Bug 240341 has been marked as a duplicate of this bug. ***
Seems to be fixed in Flash Player 7 (r25), which is released today on
http://www.macromedia.com/shockwave/download/download.cgi?P1_Prod_Version=ShockwaveFlash&P2_Platform=Linux
yes, that's fixed for now.
Status: NEW → RESOLVED
Closed: 18 years ago
Resolution: --- → FIXED
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.