While scrolling Fennec UI remote-viewport we do call SynthesizeMouseMove from PresShell::DidDoReflow http://mxr.mozilla.org/mozilla-central/source/layout/base/nsPresShell.cpp#7865 IIRC that is needed in order to update cursor position when FF scrolled with mouse wheel, but cursor stay on the same screen position (content behind cursor changed).... I think this is just wasting CPU time Event handling, dispatching HitTest calls just for nothing on Mobile... And I think we should find some conditions which help us to disable this for Mobile fennec UI process...
Created attachment 533311 [details] [diff] [review] Disable synthMouseMove for mobile
Assignee: nobody → romaxa
Status: NEW → ASSIGNED
Not sure about other platforms which could use MOBILE_OPTIMIZE_GFX but possible having mouse pointer... like neetbooks et.c... Probably it is better to make some pref, and control it per XUL application client.
Created attachment 533314 [details] [diff] [review] Pref version of synthMouseMove disable should be more flexible for different platforms handling and different xulrunner applications
Created attachment 533317 [details] [diff] [review] Pref version of synthMouseMove disable ups, typo bug
Comment on attachment 533311 [details] [diff] [review] Disable synthMouseMove for mobile Hmm. Why is a gfx-specific define the right thing to condition this on?
Comment on attachment 533311 [details] [diff] [review] Disable synthMouseMove for mobile yep, I think GFX define is bad way to disable it and not flexible...
Comment on attachment 533317 [details] [diff] [review] Pref version of synthMouseMove disable This looks fine, but why not just make that a live pref using a bool pref cache?
Attachment #533317 - Flags: review?(bzbarsky) → review+
Created attachment 534080 [details] [diff] [review] Version with cacheBool var
Comment on attachment 534080 [details] [diff] [review] Version with cacheBool var This is going to add a new cache on each DidReflow call.
Attachment #534080 - Flags: review?(bzbarsky) → review-
Created attachment 534135 [details] [diff] [review] Version with cacheBool var v2 Did not found any static initialize function in PresShell, so I hope it is ok to reuse static condition in PresShell ctor. registeredReporter
Comment on attachment 534135 [details] [diff] [review] Version with cacheBool var v2 r=me
Attachment #534135 - Flags: review?(bzbarsky) → review+
Attachment #533317 - Attachment is obsolete: true
The push from comment 12 appears to have caused orange in mochitest-chrome on all platforms: > layout/style/test/chrome/test_hover.html | Test timed out. Sample log: http://tinderbox.mozilla.org/showlog.cgi?log=Cedar/1306088180.1306089707.19816.gz http://tbpl.mozilla.org/?tree=Cedar&rev=dfeab223be6d Backed out: http://hg.mozilla.org/projects/cedar/rev/dfeab223be6d
(In reply to comment #13) > Backed out: > http://hg.mozilla.org/projects/cedar/rev/dfeab223be6d er sorry, that's the original push. backout push was: http://hg.mozilla.org/projects/cedar/rev/8176003df609
If the pref isn't specified does it maybe default to returning false?
Er, yes. There's an optional third argument (I hate optional arguments) for what the default value should be, defaulting to false. I should have caught that... :(
Created attachment 534436 [details] [diff] [review] Added default value Hm, I saw in other implementations static variable initially initialized with some default value, and I though that AddBoolPrefVarCache will take value pointer and check it's value and set it as default (we had this before somewhere in GTK API).. But ok, here is one more default value passed
Attachment #534436 - Flags: review?(bzbarsky) → review+
Status: ASSIGNED → RESOLVED
Last Resolved: 8 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla7
You need to log in before you can comment on or make changes to this bug.