Open Bug 58409 Opened 25 years ago Updated 8 months ago

GetPosition and GetPositionSlowly call to the prefs service _every_time_

Categories

(Core :: DOM: Selection, defect, P4)

defect

Tracking

()

mozilla1.1alpha

People

(Reporter: shaver, Unassigned)

Details

(Keywords: good-first-bug, perf)

Attachments

(3 files)

...which just seems wasteful. I considered a couple of solutions to this: 1) cache the pref value on the frame, and add an updater Not very good: you'd have tons of pref updaters, and it'd cost us 4 bytes per nsTextFrame object 2) cache the pref value in a static value, and install an updater the first time through the code (or until it works, if it fails) Much better. I'll attach a patch to that effect.
The patch mostly looks good (thanks for doing this -- should help a lot!), but I have one concern: in the embedded case, where we don't necessarily have a pref service, we'll keep calling SetDragOutOfFrameStyleUpdater() every time. It might be better to just assume one setting or the other (I'd vote for the Mac/Unix setting because more platforms use it and I wonder whether Windows people really *like* the Windows setting ...) in the case where we can't get the pref service, rather than leaving it undefined so we try again next time.
Assignee: mjudge → anthonyd
Target Milestone: --- → mozilla0.9
reassign to anthonyd, setting to moz0.9, anthony can you modify the patch based on Akkana's input and get this one reviewed and checked in?
can do! anthonyd
Status: NEW → ASSIGNED
okay, i got shaver's patch with akkana's changes in my tree. i will diff it up and attach it shortly for r= and sr='s. anthonyd
Whiteboard: FIX IN HAND
Cc'ing alecf. Alec, you said that nsIPref::RegisterCallback will eventually disappear. Would you please take a look at this patch? They are registering a callback to update a global variable (and not unregistering the callback at all, since that variable is global, after all). In this kind of case, would we really want to create an nsIObserver on the heap and store a pointer to it in a static variable, just so that we can call addObserver/removeObserver? Or will we end up keeping RegisterCallback around for these types of situations? Also, if RegisterCallback really is going to be removed, shouldn't there be a comment to that effect in nsIPref.idl? Also, the patch doesn't seem to address Akkana's concern (embeddor may not have prefs), even though you say that you addressed her concern.
normally you might just figure out what global service might actually own the global variable, and then make that the observer in this case though, it does look like the right thing is to just make a single local observer to observe this topic..
setting to mozilla 0.8.1 anthonyd
Target Milestone: mozilla0.9 → mozilla0.8.1
moving to mozilla0.9
Target Milestone: mozilla0.8.1 → mozilla0.9
I should add that I think that in the name of improving performance ASAP, we should just use RegisterCallback for now.
Moving to mozilla0.9.1.
Whiteboard: FIX IN HAND
Target Milestone: mozilla0.9 → mozilla0.9.1
moving to 0.9.2
Target Milestone: mozilla0.9.1 → mozilla0.9.2
im gonna reassign this to shaver since everyone but me and him doesnt seem to like the patch. anthonyd
Assignee: anthonyd → shaver
Status: ASSIGNED → NEW
Asa just told me that we shipped 0.9.2! Who knew?
Target Milestone: mozilla0.9.2 → mozilla0.9.3
Keywords: perf
Target Milestone: mozilla0.9.3 → mozilla0.9.4
What about simply caching this in the presentation context and using the nsIPresContext::GetCachedBoolPref() stuff?
Target Milestone: mozilla0.9.4 → mozilla0.9.5
->0.9.5 since we have run out of time
I recently added a sibling nsIPresContext::GetCachedIntPref() if preferred here.
I'm going to give this back to anthonyd, to either fix or WONTFIX at his leisure. I don't have time to chase this any more.
Assignee: shaver → anthonyd
Target Milestone: mozilla0.9.5 → ---
changing selection qa to tpreston.
QA Contact: blaker → tpreston
reassigning to mjudge. mike come talk to me about this one if you want.
Assignee: anthonyd → mjudge
Status: NEW → ASSIGNED
Target Milestone: --- → mozilla1.1alpha
Assignee: mjudge → nobody
Status: ASSIGNED → NEW
QA Contact: tpreston → selection

Bulk-downgrade of unassigned, >=5 years untouched DOM/Storage bugs' priority.

If you have reason to believe this is wrong (especially for the severity), please write a comment and ni :jstutte.

Severity: normal → S4
Priority: P3 → P5

The attached patch is no longer the right fix, but sadly, this report is still relevant.

We should at the very least be using static prefs here.

Keywords: good-first-bug
Priority: P5 → P4
Hardware: x86 → All
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: