Closed Bug 62891 Opened 24 years ago Closed 22 years ago

WRMB: Pages with plugins flicker on Mac

Categories

(Core Graveyard :: Plug-ins, defect, P3)

Product:
Core Graveyard
Component:
Plug-ins
Platform:
PowerPC
Mac System 8.6
Type:
defect

Tracking

(Not tracked)

Status:
VERIFIED FIXED
Milestone:
mozilla1.0.1

People

(Reporter: peterlubczynski-bugs, Assigned: peterl-bugs)

References

Details

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

Attachments

(3 files)

patch to reduce flicker on pages that have hidden plugins
656 bytes, patch
Details | Diff | Splinter Review
real patch to reduce flicker on pages that have hidden plugins
657 bytes, patch
Details | Diff | Splinter Review
patch to add pref "plugin.enable_double_buffer"
1.55 KB, patch
Details | Diff | Splinter Review 
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.
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
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.
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?
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

If you see no regressions then a=av. st still needed.
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.
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. 
added mozilla0.8, nsbeta1 keywords
Keywords: mozilla0.8, nsbeta1
Status: NEW → ASSIGNED
Setting milestone to future
Target Milestone: --- → Future
Keywords: mozilla0.8.1
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
Status: NEW → ASSIGNED
Depends on: 56128
Target Milestone: Future → mozilla1.0
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?
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
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.
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?
ra=av

Just curious, what kind of code will be generated out of 0; statement?
Need to remove "PR_FALSE;\n" so that the conditional statement actually changes
the value of the PR_BOOL.
What do you mean? It is not a return value that is used.
I'm sorry, why is it wrong to initilize to PR_FALSE?
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


Something like

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

would make sense if it were assigned to the return value of the getter.
#@$%~! - sorry about that, clearly (now) mistaken.
I checked in and it's only going to be temporary anyway so we can test this out 
with the new view manager.
*** Bug 64295 has been marked as a duplicate of this bug. ***
*** Bug 82164 has been marked as a duplicate of this bug. ***
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!
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.
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.
Whiteboard: add to all.js: pref("plugin.enable_double_buffer","true"); to test
*** Bug 94483 has been marked as a duplicate of this bug. ***
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
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
Blocks: 64833
Blocks: 104166
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. ***
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
*** Bug 111767 has been marked as a duplicate of this bug. ***
Top page of Yahoo! JAPAN flickers again
when moving scrollbar on 2002030608/Mac OS 9.2.
http://www.yahoo.co.jp/
mac os 8.6 is not supported, flickering was resolved through another bug
Status: ASSIGNED → RESOLVED
Closed: 22 years ago
Resolution: --- → FIXED
v
Status: RESOLVED → VERIFIED
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?
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
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: