Closed
Bug 568612
Opened 14 years ago
Closed 14 years ago
Remote GetURIGeckoFlags | SetURIGeckoFlags
Categories
(Core :: IPC, defect)
Core
IPC
Tracking
()
RESOLVED
FIXED
People
(Reporter: dougt, Assigned: dougt)
References
Details
Attachments
(3 files)
(deleted),
patch
|
dougt
:
review-
|
Details | Diff | Splinter Review |
(deleted),
patch
|
roc
:
review+
|
Details | Diff | Splinter Review |
(deleted),
patch
|
roc
:
review+
|
Details | Diff | Splinter Review |
http://mxr.mozilla.org/mozilla-central/source/docshell/base/nsIGlobalHistory3.idl#90
Currently we use this api to remember if a scrollbar is needed or not for a given uri.
I suppose it needs to be remoted.
Comment 1•14 years ago
|
||
Will getting it from the chrome process be fast enough that it's faster than guessing wrong on the scrollbar?
Assignee | ||
Comment 2•14 years ago
|
||
not sure; probably something we can measure. getting the response would involve to process switches and possible thread switches in both processes.
Assignee: nobody → dougt
Attachment #447822 -
Flags: review?
Assignee | ||
Updated•14 years ago
|
Attachment #447822 -
Flags: review? → review?(bzbarsky)
Comment 3•14 years ago
|
||
Well, hold on. In the chrome process there's no point for this. This is only worth it in the process that handles web content.
Assignee | ||
Comment 4•14 years ago
|
||
bz, consider the case where there is only one process (e.g. the chrome process). This is the case that Firefox desktop will be in until it supports e10s. It will have MOZ_IPC defined, but no elements will be remoted. Surely, in this case, we should attempt to remember the gecko flags.
Comment 5•14 years ago
|
||
In bug 556400 we were talking about dropping nsIGlobalHistory3 all together. Do need these bits still?
When I landed this, the speedup we got was very small.
It's probably worth re-running Tp4 to see if there's measurable difference with them removed.
Comment 7•14 years ago
|
||
> Surely, in this case, we should attempt to remember the gecko flags.
Should we? If we're planning to stop doing this anyway, why not stop now and remove complexity instead of adding it?
Assignee | ||
Comment 8•14 years ago
|
||
roc - the reason that it didn't make any speed up was that the history backed didn't record anything:
http://mxr.mozilla.org/mozilla-central/source/toolkit/components/places/src/nsNavHistory.cpp#5535
Assignee | ||
Comment 9•14 years ago
|
||
Attachment #448021 -
Flags: review?(roc)
Assignee | ||
Updated•14 years ago
|
Attachment #448021 -
Attachment is patch: true
Attachment #448021 -
Attachment mime type: application/octet-stream → text/plain
Comment 10•14 years ago
|
||
fwiw, when roc added this code (the time he's referring to in comment 6) is pre-places; at the time the history backend did in fact record the information.
Comment on attachment 448021 [details] [diff] [review]
remove the calls.
I'm not completely happy that that optimization was just disabled by Places, but I guess this is the best thing to do for now.
Attachment #448021 -
Flags: review?(roc) → review+
Comment 12•14 years ago
|
||
fwiw, we had a bug on places for this. It's been around for years now, obviously, with not much attention.
Assignee | ||
Updated•14 years ago
|
Attachment #447822 -
Flags: review?(bzbarsky) → review-
Assignee | ||
Comment 13•14 years ago
|
||
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
Comment 14•14 years ago
|
||
This bug's patch removed the last use of the static helper-function "GetDocURI", so now we get:
> layout/generic/nsGfxScrollFrame.cpp:3302: warning: 'nsIURI* GetDocURI(nsIFrame*)' defined but not used
The attached followup-patch removes this method.
Updated•14 years ago
|
Attachment #450281 -
Flags: review?(roc)
Updated•14 years ago
|
Version: unspecified → Trunk
Attachment #450281 -
Flags: review?(roc) → review+
Comment 15•14 years ago
|
||
landed followup: http://hg.mozilla.org/mozilla-central/rev/3675017ddaa1
You need to log in
before you can comment on or make changes to this bug.
Description
•