Remove fake mouse move hack.

Remove fake mouse move hack.
 Removing the hack because the original problem has already been fixed.
 This takes 10+ms on cr48 and is one of causes of UI jank-ness on chromeos.

BUG=13389, chromium-os:8632
TEST=tested repo step in crbug.com/12879 and confirmed that the original problem has fixed.

Committed: http://src.chromium.org/viewvc/chrome?view=rev&revision=76428

[Evan Stade, 2011-03-01 21:06:10]

LGTM

so is the 10ms coming from gtk_widget_get_pointer? Are you looking at removing
other uses of this function?

[oshima, 2011-03-01 21:36:28]

On Tue, Mar 1, 2011 at 1:06 PM, <estade@chromium.org> wrote:

> LGTM
>
> so is the 10ms coming from gtk_widget_get_pointer?

Yes, on cr48.


> Are you looking at removing
> other uses of this function?


This seems to be fast enough on normal desktop so I have no plan to
remove it from ui/gtk code.
There are other two instances in render_widget_host_view_gtk and one in
MouseMoveEvent
seems to be worth looking into. I guess this happens when you mouse over
plugin window?

- oshima



>
>
> http://codereview.chromium.org/6588075/
>

[Evan Stade, 2011-03-01 22:32:02]

let's see...

the one in ButtonPressReleaseEvent seems to be for popup render views (i.e.
select dropdowns and autocomplete dropdowns). I think the select dropdowns grab
the mouse pointer, so they can get mouse down events that originated in a
different widget, such as the web page render view, which has a different top
level window (the main chrome window), so we have to do a round trip to X to get
the coordinates relative to the popup window. If they shared a toplevel window,
we could use gtk_widget_translate_coordinates instead, but they don't. Instead
of gtk_widget_get_pointer, we could use gtk_window_get_position to translate the
coordinates, however we'd have to do it twice. You could investigate if that is
faster.

Same thing applies to MouseMoveEvent.

These uses do suck, but the mitigating factor is that the code path is not
frequently hit (probably only when you have a select dropdown open).

[oshima, 2011-03-02 23:21:56]

On Tue, Mar 1, 2011 at 2:32 PM, <estade@chromium.org> wrote:

> let's see...
>
> the one in ButtonPressReleaseEvent seems to be for popup render views (i.e.
> select dropdowns and autocomplete dropdowns). I think the select dropdowns
> grab
> the mouse pointer, so they can get mouse down events that originated in a
> different widget, such as the web page render view, which has a different
> top
> level window (the main chrome window), so we have to do a round trip to X
> to get
> the coordinates relative to the popup window. If they shared a toplevel
> window,
> we could use gtk_widget_translate_coordinates instead, but they don't.
> Instead
> of gtk_widget_get_pointer, we could use gtk_window_get_position to
> translate the
> coordinates, however we'd have to do it twice. You could investigate if
> that is
> faster.
>
> Same thing applies to MouseMoveEvent.


> These uses do suck, but the mitigating factor is that the code path is not
> frequently hit (probably only when you have a select dropdown open).
>
>
I see. Thank you for explanation.


>
> http://codereview.chromium.org/6588075/
>