WRMB: Pages with plugins flicker on Mac

VERIFIED FIXED in mozilla1.0.1

Status

()

Core
Plug-ins
P3
normal
VERIFIED FIXED
18 years ago
16 years ago

People

(Reporter: Peter Lubczynski, Assigned: Peter Lubczynski)

Tracking

Trunk
mozilla1.0.1
PowerPC
Mac System 8.6
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [bugscape: 5534]add to all.js: pref("plugin.enable_double_buffer","true"); to test)

Attachments

(3 attachments)

(Reporter)

Description

18 years ago
Due to the fact that double buffering is turned off in the view manager for
pages with plugins, the entire page flickers. It would provide a much better
user experience if the page didn't flicker.

Comment 1

18 years ago
Created attachment 20737 [details] [diff] [review]
patch to reduce flicker on pages that have hidden plugins

Comment 2

18 years ago
Created attachment 20738 [details] [diff] [review]
real patch to reduce flicker on pages that have hidden plugins

Comment 3

18 years ago
The flicker on pages with plugins is pretty nasty.  It's worse for the user 
when the plugin is not visible since there's nothing for them to attribute the 
cause to.  Most pages that use the Beatnik plugin have it hidden.  Attached is 
a patch that leaves double buffering enabled on pages that have hidden plugins.
Keywords: beatnik
(Reporter)

Comment 4

18 years ago
The patch looks like a good idea and a big win for hidden plugins on Mac. 

Sean, can you attach a testcase or link with a hidden plugin to verify this 
doesn't cause other problem.
(Reporter)

Comment 5

18 years ago
I tested out Sean's patch by downloading the Beatnik plugin and visiting their 
site. His patch definitely doesn't fix this problem for all cases, but it does 
really help to make a better user experience for hidden plugins like beatnik.

Andre, can I get module-owner approval to check this in?

Comment 6

18 years ago
I've been running with this patch installed in my tree for a week now with no 
problems. I'll vouch for the review, but you'll still have to find an sr.
r = bnesse

Comment 7

18 years ago
If you see no regressions then a=av. st still needed.

Comment 8

18 years ago
as long as you've tested this with a case where the hidden plugin is dynamically
shown and hidden, then I'm happy with the change.  sr=buster.
(Reporter)

Comment 9

18 years ago
I think Buster may be right on this one. The patch only checks for a hidden 
plugin during widget creation. If the plugin is made visible through the DOM or 
style, then double buffering will still be on and you probably won't see the 
plugin. I haven't tested this and I don't even know if changing visibility 
currently works with plugins. 

Comment 10

18 years ago
added mozilla0.8, nsbeta1 keywords
Keywords: mozilla0.8, nsbeta1

Updated

18 years ago
Status: NEW → ASSIGNED
Setting milestone to future
Target Milestone: --- → Future

Updated

18 years ago
Keywords: mozilla0.8.1

Updated

18 years ago
Keywords: mozilla0.8
nominating for dogfood (from sdagley's list of bugs that are good candidates for 
our next release) 
Keywords: nsdogfood
Reassigning to peterl@netscape.com. Peter this is more in your area. If we
received the correct damage rect we could be more efficient, but until then we
have to resort to turning the viewmanager's double-buffering off. 
Assignee: kmcclusk → peterl
Status: ASSIGNED → NEW
(Reporter)

Updated

18 years ago
Status: NEW → ASSIGNED
Depends on: 56128
Target Milestone: Future → mozilla1.0
(Reporter)

Comment 14

18 years ago
Kevin, could it be possible to turn double buffering back on for Mac plugins if 
the plugin's widget could be identified as being a plugin during bit blit and 
just be clipped out? What do you think?
(Reporter)

Comment 15

18 years ago
Robert,

Kevin says the new ViewManager may fix this. What's the pref to turn it on?
user_pref("nglayout.debug.enable_scary_view_manager", true);
Keywords: nsCatFood
Keywords: nsdogfood
(Reporter)

Comment 17

18 years ago
Kevin,

You were right [again]. I think Robert's new ViewManger let's you leave double 
buffering on for page with plugins on the Mac. I'm thinking this may require a 
lot of testing, so I'll attach a patch shortly which can activate double 
buffering for plugin pages on a run-time basis for QA to try.
(Reporter)

Comment 18

18 years ago
Created attachment 30801 [details] [diff] [review]
patch to add pref "plugin.enable_double_buffer"
(Reporter)

Comment 19

18 years ago
The above patch adds a pref so that one can leave double buffering on with pages 
with plugins. This is temporary and experimental for testing purposes. If after 
testing, we can leave on double buffering for pages with plugins, we can take 
this out along with the double buffering code.

To turn on double buffering for all web pages add this pref:
pref("plugin.enable_double_buffer", true);


Kevin, Andrei, can I get reviews?

Comment 20

18 years ago
ra=av

Just curious, what kind of code will be generated out of 0; statement?

Comment 21

18 years ago
Need to remove "PR_FALSE;\n" so that the conditional statement actually changes
the value of the PR_BOOL.

Comment 22

18 years ago
What do you mean? It is not a return value that is used.
(Reporter)

Comment 23

18 years ago
I'm sorry, why is it wrong to initilize to PR_FALSE?

Comment 24

18 years ago
I'm not sure what sean is thinking... It looks fine to me. Personally, i'd
change this:

prefs ? prefs->GetBoolPref("plugin.enable_double_buffer", &doubleBuffer) : 0;

to this:

if (prefs) {
  prefs->GetBoolPref("plugin.enable_double_buffer", &doubleBuffer);
}

but I won't try to force you ;)

sr=attinasi

Comment 25

18 years ago
Something like

PRBool doubleBuffer = prefs ? prefs->GetBoolPref("...") : 0;

would make sense if it were assigned to the return value of the getter.

Comment 26

18 years ago
#@$%~! - sorry about that, clearly (now) mistaken.
(Reporter)

Comment 27

18 years ago
I checked in and it's only going to be temporary anyway so we can test this out 
with the new view manager.
(Reporter)

Comment 28

18 years ago
*** Bug 64295 has been marked as a duplicate of this bug. ***

Comment 29

17 years ago
*** Bug 82164 has been marked as a duplicate of this bug. ***
(Reporter)

Comment 30

17 years ago
Bug 82164 talks about animated gifs with plugins. Shrirang, if you have a 
moment, can you try a testcase with animated gifs and let me know if this is 
really, really bad or just regular bad.

Thanks!

Comment 31

17 years ago
i put up the testcase at http://slip/shrir/Dice_2.html . Tried today's mac 
0522 build, with double bufering 'off' , i can see what andrew said. But I guess 
we can live with it since it is not that bad. With double buffering 'on' , it 
works smoothly though.

Updated

17 years ago
Keywords: beatnik
A real-world test site showing this problem: http://www.neopets.com/.  Problem
still present in 2001071913, just in case anyone was wondering.  What are the
plans to fix this?  It looks pretty bad on the site mentioned.
(Reporter)

Updated

17 years ago
Whiteboard: add to all.js: pref("plugin.enable_double_buffer","true"); to test
(Reporter)

Comment 33

17 years ago
*** Bug 94483 has been marked as a duplicate of this bug. ***

Comment 34

17 years ago
adding WRMB to summary, please refer to bugscape bug 5317 for more 
detail/history of this issue
Summary: Pages with plugins flicker on Mac → WRMB: Pages with plugins flicker on Mac

Comment 35

17 years ago
adding topembed and bugscape ref
Keywords: topembed
Whiteboard: add to all.js: pref("plugin.enable_double_buffer","true"); to test → [bugscape: 5534]add to all.js: pref("plugin.enable_double_buffer","true"); to test

Updated

17 years ago
Blocks: 64833

Updated

17 years ago
Blocks: 104166

Comment 36

17 years ago
removing topembed designation (Mac and the corresponding bugscape bug is not P1)
Keywords: topembed
*** Bug 101412 has been marked as a duplicate of this bug. ***

Comment 38

17 years ago
Bugs targeted at mozilla1.0 without the mozilla1.0 keyword moved to mozilla1.0.1 
(you can query for this string to delete spam or retrieve the list of bugs I've 
moved)
Target Milestone: mozilla1.0 → mozilla1.0.1

Comment 39

17 years ago
*** Bug 111767 has been marked as a duplicate of this bug. ***

Comment 40

17 years ago
Top page of Yahoo! JAPAN flickers again
when moving scrollbar on 2002030608/Mac OS 9.2.
http://www.yahoo.co.jp/

Comment 41

16 years ago
mac os 8.6 is not supported, flickering was resolved through another bug
Status: ASSIGNED → RESOLVED
Last Resolved: 16 years ago
Resolution: --- → FIXED

Comment 42

16 years ago
v
Status: RESOLVED → VERIFIED

Comment 43

16 years ago
Using 2002053011-trunk/Mac OS 9.2, Shockwave Flash 5.0 r41,
go to http://www.yahoo.co.jp/ and move scrollbar,
then *scrollbar* flickers.
Is this another bug?

BTW Mac OS 8.6 is not supported?

Comment 44

16 years ago
http://www.mozilla.org/releases/mozilla1.0
System Requirements
Macintosh
Mac OS 8.5 or later 
PowerPC 604e 266 MHz or faster processor, or G3/G4 
64 MB RAM 
36 MB of free hard disk space 
QuickTime (Bug 59059)

[jwz "Speak for yourself"]
http://216.239.37.100/search?q=cache:apVbOsa7npIC:www.mozilla.org/README-
style.html+"likely+wear+two+hats"+"you+don't+speak+for+mozilla.org"+site:mozilla
.org
You need to log in before you can comment on or make changes to this bug.