07-27-2010 07:21 AM
High level goal is to update mouse position smoothly.
I am thinking to achieve that, I need to detect navigation movement in fixed frequency.
Having a listener or override navigationMovement() is not enough because it is called when there is a navigation movement and when the event queue gets to it.
It the app is busy, this call will be delayed since event queue does not get to it fast enough make me to update the mouse position in choppy fashion.
I am saying I need to update mouse position smoothly; that's a lie for simplicity sake.
Basically, I need to update the position of my object smoothly based on navigation movement made by user and I need to check it in fixed frequency instead of relying on event queue.
Thanks in advance, expers.
Solved! Go to Solution.
07-27-2010 07:25 AM
this is not possible, the event queue is the only option to interact.
you could lower your background processing or remove blocks from the ui thread to improve performance.
07-27-2010 07:37 AM
Thank you for your reply, simon_hain.
That's sad to know, but I will wait for awhile for maybe someone knows a workaround.
Otherwise, I will try harder to make the background process lighter and accept your post as an answer.
Anyway, can't I call Application.getEventLock() and call a function to check if there is navigation movement event occured?
Can I look the size of the event queue? Prioritize a thread in the queue or something?
I am just trying to brainstorm for possibilities here.
07-27-2010 07:47 AM
I don't think any of that is possible or would make a difference. The only thing that I can think of is if you use variable to keep track of the amount of movement that the trackball as gone in a certain time period and have a timer or thread that smoothly moves it until the total distance has been reached.
Instead of moving based on the dx and dy in the trackabll movement method, add these values to global variables, then inside your paint move the cursor by x amount an subtract that from the global amounts, that way even if it freezes the movement will be smooth since you are controlling the movement by a fixed amount. It also should keep it synchronized since both occur on the event thread I think, and so both paint and movement should not be able to occur at the same time.
07-27-2010 07:50 AM
When a navigation event occurs, navigationMovement / navigationClick /navigationUnclick is called. The highest level where you can override them is Screen; from there, you can register that event somewhere in your internal objects and return true (event consumed). Later on, when your TimerTask executes its run(), you can check that object to see whether there was any new navigation event.
Does that make any sense?
However, if your application manages to slow the phone down too much, you won't get those events immediately (and your TimerTask will start missing the scheduled times). Even worse would be any blocking and/or CPU-heavy calls on the UI thread, which is what Simon hinted at in his reply. A BlackBerry programmer, especially real-time-like application designer (are you making an arcade game?) has to be almost religious about not running anything serious on the UI thread. Review your application and eliminate all such places - you'll be much better off.
07-27-2010 08:29 AM
Can I ask what sort of Screen is being displayed at the time? Is this for a game, in which case the entire screen is managed by the Application, or for a normal BlackBerry application, in which case there is no cursor, and focus is indicated by the currently in focus field, and jumps between focusable fields?
07-27-2010 12:21 PM
Thank you all. Good and very helpful replies!
Yes this is for a game and I am using FullScreen, managed by Application.
The computation should not be heavy (or is it?), top is in hundreds computations per 50ms.
Not including the drawing part in paint(). I am trying to minimize the number of computation in paint() since it's running in event thread I guess?
I am trying what CMY suggested, and reduce more computations.
Any more great idea?
Thank you much!
07-27-2010 12:46 PM
I would say move as many computations as possible to a background Thread/TimerTask. That background Thread should calculate new positions, new objects on the screen, etc. and put them in some global variables. Once anything that would affect the screen changes, call invalidate() on the whole screen or on the part you know is affected.
Your paint should only take the necessary values from the global variables and use graphics primitives to paint them. Those primitives are really fast and won't take too much time.
Your navigationMovement() / navigationClick() / touchEvent() should just add their "events" to your internal queue and return true. Your background Thread will check that queue for new events and take them into account.