My guess is the surface transaction related handling caused the
recomputation of the whole screen. I have observed with the diaglo on,
system_server used lots of cpu time.
So we may need to find some better approach in drawing the cursor.
Can some one from google give some comments? Thanks.
--
Chen
2009/5/21 Yi Sun <beyo...@gmail.com>
> This code is wrong (Ya, I did it). But, it should not be the reason of the
> slowness. The position convert should not happen here. Otherwise, the event
> batch will crew up the position value in the original event. Even after I
> fixed it, the slowness is still there. One thing I have observed is that
> the performance issue only happens when we use it in multiple select window.
> For the other cases, it seems to be ok.
>
> One more problem is that when I drag an icon around window, the icon has
> never moved to the place I want. The position value seems correct, need to
> dig more when have time.
>
>
> 2009/5/20 Chen Yang <sunsety...@gmail.com>
>
> The mouse cursor works! Thanks to Yi for your great work! :)
>> I also observed the same as Chih-wei, if there are some dialog appears,
>> the mouse cursor responds very slowly. To have a try, you can just try in
>> the home screen, long press the mouse and then one dialog will pop up, then
>> you can try to move the mouse, it responds to the move very slowly. I guess
>> it may relate to some computation internally to dim to background. But i
>> haven't done any extra investigation. Given the vesafb's large screen and
>> lack of hardware acceleration, the dim computation may take some cpu cycles.
>>
>> So one question raises: is there some better implementation to draw the
>> mouse cursor? I am attaching the drawing here, and highly appreciate the
>> suggestions! Thanks.
>>
>> @@ -5119,6 +5134,44 @@ public class WindowManagerService extends
>> IWindowManager.Stub implements Watchdo
>> //Log.i(TAG, "Read next event " + ev);
>> dispatchPointer(ev,
>> (MotionEvent)ev.event, 0, 0);
>> break;
>> + case RawInputEvent.CLASS_MOUSE:
>> + MotionEvent mmev = (MotionEvent)ev.event;
>> + int mcx = mMlx + (int)(mmev.getX()*
>> mmev.getXPrecision());
>> + int mcy = mMly + (int)(mmev.getY()*
>> mmev.getYPrecision());
>> + mcx = ((mcx < 0) ? 0 :(mcx >=
>> mDisplay.getWidth() ?(mDisplay.getWidth()-1):mcx));
>> + mcy = ((mcy < 0) ? 0 :(mcy >=
>> mDisplay.getHeight()?(mDisplay.getHeight() - 1):mcy));
>> +
>> + mmev.setLocation((float) mcx, (float)
>> mcy);
>> + dispatchPointer(ev, mmev, 0, 0);
>> + if (mMouseSurface != null && (mMlx != mcx
>> || mMly != mcy)) {
>> + // Should we use lock?
>> synchronized(mWindowMap) {
>> + Surface.openTransaction();
>> + if (DEBUG_INPUT)
>> + Log.i(TAG,
>> + "Open transaction for the
>> mouse surface");
>> + WindowState top =
>> +
>> (WindowState)mWindows.get(mWindows.size() - 1);
>> + try {
>> + if (DEBUG_INPUT)
>> + Log.i(TAG, "Move surf, x: "
>> +
>> + Integer.toString(mcx) +
>> " y:"
>> + +
>> Integer.toString(mcy));
>> +
>> +
>> mMouseSurface.setPosition(mcx,mcy);
>> +
>> mMouseSurface.setLayer(top.mAnimLayer + 1);
>> + if (mShowMouse != 1) {
>> + mMouseSurface.show();
>> + mShowMouse = 1;
>> + }
>> + mMlx = mcx;
>> + mMly = mcy;
>> + } catch ( RuntimeException e) {
>> + Log.e(TAG, "Failure showing mouse
>> surface",e);
>> + }
>> + Surface.closeTransaction();
>> + }
>> +
>> + break;
>> --
>> Chen
>>
>> On Fri, May 8, 2009 at 11:48 PM, Yi Sun <beyo...@gmail.com> wrote:
>>
>>>
>>> CHih-wei,
>>> Could you document the test results in the project wiki? THanks
>>> Yi
>>> On Fri, 2009-05-08 at 00:40 -0700, Chih-Wei wrote:
>>> > I've done more tests on all EeePC I can access, including
>>> > 701/701SD/900/900A/901/904HD/1000/1000HD.
>>> > (using the same kernel image, of course)
>>> > The touchpad works for all models, except 701. Very strange...
>>> >
>>> > However, I noticed a strange behavior.
>>> > If there is a popup message box (e.g., XXX is closed unexpected),
>>> > the mouse cursor becomes very slow and irresponsive.
>>> > After closing the message box, the cursor becomes normal.
>>> > Any comment?
>>> >
>>> > On 5月8日, 上午12時55分, Yi Sun <beyo...@gmail.com> wrote:
>>> > > A..... I don't know :-). Ok, let me try to find a 701, If I can get
>>> one,
>>> > > I will try it out.
>>> > > At the meanwhile, I will post the new patch.
>>> > > Yi
>>> > >
>>> > > On Wed, 2009-05-06 at 23:29 -0700, Chih-Wei wrote:
>>> > > > Hi Yi,
>>> > > > Indeed I took that configuration (plus some additional drivers).
>>> > > > The following options are enabled:
>>> > > > CONFIG_INPUT_MOUSE=y
>>> > > > CONFIG_MOUSE_PS2=y
>>> > > > CONFIG_MOUSE_PS2_ALPS=y
>>> > > > CONFIG_MOUSE_PS2_LOGIPS2PP=y
>>> > > > CONFIG_MOUSE_PS2_SYNAPTICS=y
>>> > > > CONFIG_MOUSE_PS2_LIFEBOOK=y
>>> > > > CONFIG_MOUSE_PS2_TRACKPOINT=y
>>> > > > CONFIG_MOUSE_PS2_TOUCHKIT=y
>>> > > > CONFIG_MOUSE_SERIAL=y
>>> > > > ...
>>> > > > I just tested it on EeePC 1000, with the same kernel image I tested
>>> on
>>> > > > 701.
>>> > > > Amazingly, the touchpad works.
>>> > > > So... what's the problem?
>>> >
>>> > >
>>>
>>>
>>>
>>>
>>>
>>>
>
> >
>
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"android-porting" group.
To post to this group, send email to android-porting@googlegroups.com
To unsubscribe from this group, send email to
android-porting+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-porting?hl=en
-~----------~----~----~----~------~----~------~--~---
