You need to log in before you can comment on or make changes to this bug.
I have been looking a little bit into the CPU usage of a Chameleon application and see that the things that occur on the mouse move event take a lot of CPU (50-100% depending on the speed of movement). Perhaps some of these functions could be on intervals which are more friendly to the CPU usage? Also, I noticed that this does not only occur when moving over the map area, but this occurs when moving over any part of the page. That's quite strange, because no coordinates etc. need to be updated when moving the mouse around outside the map area.
this happens because the mousemove event of the document object is used to track mouse movement and all widget handlers are called every time the mouse moves, regardless of location of map. This will is planned to be fixed prior to Mar 31st on contract with NRCan.
Assefa has committed fixes for this in the latest cvs. The mouse handling has been restricted to the map image and has resulted in significantly less processor usage when moving the mouse over the rest of the page.
Does this mean nothing will be done about the high CPU consumption when moving the mouse in the map area? This is still a problem in my opinion especially with a lot of tools in your template. Maybe the mousemove should only be tracked for the active maptools?
Can somebody make comments on this bug or even verify how this bug was set to "Resolved Fix". Thanks
Chris could check with the Windows tool accessed by pressing "ctrl-alt-del"?
Bart, please verify this bug has been fixed to your satisfaction. For the record, on windows you can use the task manager to view the CPU useage of the browser's process and it was quite evident on most platforms that CPU useage would max out when moving the mouse over a moderately complex chameleon application, even if the mouse was not over the map. Now there is no CPU activity change when moving the mouse over the page until you move over the map. And even this should be moderately better.
Paul, outside the map area it is okay now. I still think the CPU consumption in the map area is too high though. I have 2 machines at my work, a Pentium III 1 Ghz, and a Pentium IV 2,8 Ghz. On the last mentioned machine it is no problem, but on the first mentioned machine the application gets really slow on mouse move in the map area especially if the ROI tools are in it. I would like to opt for a mechanism where only the active tool (or active tools) listen to mouse movement on the map. It is likely that more and more tools are developed and used per application in the future, which will increase the scope of this problem. But maybe that should be discussed in another bug? BTW: is it the same problem that is causing the pan not to work smoothly in Mozilla? The clipping lags behind.
Let's close this bug and open a new one for modifying the navigation tool activation/tracking mechanism ... this could be targetted for version 2.1
based on comment #8 by Paul this bug should be closed, there is no reference to the new bug to be opened. Can someone please tell this bug what is the new bug. :) So I can close it.
Changing the target to "-" since this will not be dealt with under beta 2
Question: Based on comment #8 we should close this bug. So why are we changing the target milestone (see comment #10)?
I am changing the target to "-" because this issue, is obviously not going to be fixed for beta 2. This is assuming that the new bug related to this issue has not been targetted. We still need to know what bug has been opened to replace this one.
