Closed Bug 169483 Opened 22 years ago Closed 22 years ago

RFE: Add prefs to enable/disable double-buffering

Categories

(Core :: Web Painting, defect)

defect
Not set
normal

Tracking

()

RESOLVED FIXED
mozilla1.2beta

People

(Reporter: roland.mainz, Assigned: roland.mainz)

Details

Attachments

(1 file, 2 obsolete files)

RFE: Add prefs to enable/disable double-buffering instead of using a compile-time switch (--disable-double-buffer).
Taking myself...
Assignee: roc+moz → Roland.Mainz
Status: NEW → ASSIGNED
Target Milestone: --- → mozilla1.2beta
Attached patch Patch for 2002-09-14-08-trunk (obsolete) — Splinter Review
Comment on attachment 99685 [details] [diff] [review] Patch for 2002-09-14-08-trunk /* Check the prefs we we should do doublebuffering or not... */ doesn't make sense, how about /* Check the prefs to see whether we should do double buffering or not */ with that, r=roc+moz
Attachment #99685 - Flags: review+
Attached patch New patch to match r=roc+moz (obsolete) — Splinter Review
Attachment #99685 - Attachment is obsolete: true
Keywords: patch, review
Comment on attachment 99688 [details] [diff] [review] New patch to match r=roc+moz r=roc+moz
Attachment #99688 - Flags: review+
Comment on attachment 99688 [details] [diff] [review] New patch to match r=roc+moz So where are the changes that set the default value? Aren't there some .js changes that need to be made in modules/libpref? If we checkin without checking in a default, won't double buffering be disabled on all platforms? Also note that the result of the following call will also overwrite whatever the pref says on some platforms like the mac: aContext->UseBackbuffer(&contextWantsBackBuffer);
Comment on attachment 99688 [details] [diff] [review] New patch to match r=roc+moz r=cls on the build change.
kin wrote: > (From update of attachment 99688 [details] [diff] [review]) > So where are the changes that set the default value? Aren't there some .js > changes that need to be made in modules/libpref? If we checkin without > checking in a default, won't double buffering be disabled on all platforms? From the patch: -- snip -- +static +PRBool DoDoubleBuffering(void) +{ + static PRBool got_doublebuffer_prefs = PR_FALSE; + static PRBool do_doublebuffering = PR_TRUE; -- snip -- |do_doublebuffering| is set to |PR_TRUE| by default - and |GetBoolPref()| does not alter that value if the matching pref is not present ((nearly) all of our |GetBoolPref()| callers do that... :) Therefore we do double-buffering except the prefs says something else. I did not provide an entry for prefs.js - this switch is more for developers who want to see how inefficient our code is (BTW: the number of (unneccesary!!) full redraws and how we render the scrollbars is _shocking_... ;-(((( ) ... > Also note that the result of the following call will also overwrite whatever > the pref says on some platforms like the mac: > > aContext->UseBackbuffer(&contextWantsBackBuffer); The new prefs is a replacement for the --disable-double-buffer "configure" switch (and exactly does the same). I've looked at the line above but I think it's better not to play with that - all h*ll may break loose if we try to force non-double-buffered mode in all cases.
Comment on attachment 99688 [details] [diff] [review] New patch to match r=roc+moz sr=kin@netscape.com
Attachment #99688 - Flags: superreview+
Actually, Roland, you should add an entry to all.js. Also, when you add the all.js setting to the patch, would you mind changing your local variables to interCaps? Thanks! BTW, the UseBackbuffer check can only turn double-buffering OFF, not on.
Robert O'Callahan wrote: > Actually, Roland, you should add an entry to all.js. OK... but I can't do that now, I am away for the rest of the week... - new patch on sunday or monday... ;-(( > Also, when you add the all.js setting to the patch, would you mind changing > your local variables to interCaps? What are "interCaps" ?!
not interCaps: do_double_buffering interCaps: doDoubleBuffering
Attachment #99688 - Attachment is obsolete: true
checked in
Status: ASSIGNED → RESOLVED
Closed: 22 years ago
Resolution: --- → FIXED
This is only useful/interesting for debugging, right?
Adam D. Moss wrote: > This is only useful/interesting for debugging, right? Yes and no. It speeds-up the rendering performance on some dumb framebuffers (those which don't have "accerlated" rect copy) therefore it may help endusers in some rare cases, too... :)
Usage: Set -- snip -- user_pref("viewmanager.do_doublebuffering", false); -- snip -- to disable double-buffering.
Component: Layout: View Rendering → Layout: Web Painting
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: