In my project I have noticed 20-40% CPU time when my app is idle.
In debugger when I pause I always land on a flex.utils.Timer/tick.
This timer has 30ms delay between "ticks"
I didn't create that Timer... so this is problably a component I have added
Unfortunately it will be difficult to remove all compenents until if find the "one" ..
Yes I should have notice the CPU usage sooner !
and yes I will do that if I don't find another solution
I am of course using some components without having their sources...
My questions :
* How can I find the guilty component ?
* I tried to find it using Kap Inspector without success ...any tips for Kap inspector ?
* Is there another great tool to track object creation ?
Thanks for your help
When you set your breakpoint, in the Flex Debugger perspective, find the Variables tab/view. From there, with your breakpoint set, you should be able to see all of the variables currently in local scope (local to the timer-tick event handler, that is). The event variable will contain information about the timer itself -- e.g., in event.target -- and the this variable will tell you where the timer handler is defined.
From there, you might be able to walk back up the stack trace, using the Debug tab/view (with your breakpoint still set), to get a sense of where the Timer object might've been instantiated. If that doesn't work, you can download a trial of Flex Builder Professional here:
http://www.adobe.com/cfusion/entitlement/index.cfm?e=flexbuilder3
... and give the built-in profiler a try. Hope that helps point you in a helpful direction!
No idea about Flex, but for your CPU problems, check this out:
http://www.gskinner.com/blog/archives/2009/05/idle_cpu_usage.html
Related
in my application, I override QMainWindow::closeEvent in order to do some logic before closing the app.
The only argument this function gets is of type QCloseEvent, and it's called whenever the user tries to close the app.
It happens when we click the X button, of course, but depending on platform we also have things like alt+f4, rightclick->close and possibly more.
My goal here is to distinguish between these. More specifically, I need to know if just the X button was pressed or not.
From to the docs, which can be found here: https://doc.qt.io/qt-5/qcloseevent-members.html
I can't see anything that would help me get this information.
There is a function spontaneous(), which allows me to check if the event was triggered programmatically or by the environment/user, but in the case I'm presenting, every event has this value as true.
Unfortunately, I don't even know if this is possible.
I expect that it could work in a way that X11 or some other component in the system would just send the same signal for every case, but I don't really know where to look for this information.
Other questions that I've found on stack cover the spontaneous vs non-spontaneous cases, thus the didn't help me.
closeEvent() is called after the window is closed, not necessarily when the application is closed. Therefore, it's not called until after all the logic for the key is processed.
Override keyEvent() and use that function to run your key press logic.
Documentation here
Is there a way without using multiple threads?
I found this https://stackoverflow.com/a/17329626/4014896
But i don't get how it works. Shouldn't it cause 100% CPU usage in the example?
and how can I embed it, for example, into QT?
there is also this: https://github.com/svalaskevicius/qt-event-dispatcher-libuv
But there is no documentation at all.
But from my looks it seems to be something that translates from example QSocket to uv_tcp_socket which is not what I'm searching for.
In short - you'll either need to merge the two event loops or use separate threads and sync the event handlers manually..
The first link you pasted shows how to process libuv events that have happened since the last invocation. The while stated there will use ~100% CPU if there are no events dispatched (as it will just keep polling).
The second link (qt-event-dispatcher-libuv) is a project I've created to tackle the same problem. It does, however, work as you described - by using libuv to handle Qt's event loop (and by doing that - merges the two event loops into one).
To use it you'd just need to register the event dispatcher in your application using http://qt-project.org/doc/qt-5/qcoreapplication.html#setEventDispatcher. An example where this library is used - https://github.com/svalaskevicius/qtjs-generator/blob/master/src/runner/main.cpp#L179
There is still one catch using this approach - while it works very well on linux, there are some problems on OS X as the Qt's Cocoa platform support plugin handles some Cocoa's event loop operations and doesn't provide a nice API to merge it as well (currently its updating them one its freed up after a small timeout so there is some (barely?) noticeable lag to handle the GUI events) - I was planning to port the platform support plugin to be able to integrate it as well but that's still in future. And I haven't tested it on windows yet :)
An alternative solution could probably be to try to merge the two loops from another direction that I've done - instead of making Qt to use libuv, libuv's api could be provided that uses Qt's handlers - although it requires a considerable amount of work as well.
Please let me know if there is any more info I could provide.
Regards,
I've been using IAR embedded workbench for quite some time but there is still one thing I'm unable to wrap my head around. And that's the inconsistency of the breakpoint operation.
I have a quite big project which runs an RTOS (might this affect the problem?) and when I place a breakpoint there is no guarantee the debugger will stop at this breakpoint. Sometimes it does, sometimes it doesn't.
A workaround I found is manually stopping the processor and placing the breakpoint while the processor is paused. But even this has not a 100% success rate.
I'm generating debug information and I'm running in debug mode
Anyone had similar issues or anyone with some ideas?
Try to reduce number of breakpoints that you use (possibly just keep this one that causes problem), also you could use a “Log” breakpoint in order to print a message in the Debug Log window instead of stopping at that point (you may also want to try a different point in the same section of the code). If they don't help, I could say with a high degree of certainty that the debugger does not stop at the breakpoint because it simply does not hit it, and you do not enter that block of code. Consider that in an embedded project (especially when using an RTOS) some conditions are met only at the beginning or upon certain requests in certain conditions so you might want to figure out when the breakpoint is actually hit what conditions were met and what is the new state now.
I have implemented a simple sync routine using the as3commons-async framework (which I thought to be stable as a rock)
I have a CompositeCommand containing a high number of other commands, which can also be composite commands.
Now some strange thing happens:
When executed slowly (over the web) everything works as expected.
Now I leave out the part doing the heavy load causing the commands to run at "machine" speed.
After a couple of dozens, sometimes more than a hundred "progress" events fired, AIR player crashes with this error message:
undefined
at org.as3commons.async.operation.impl::AbstractProgressOperation/dispatchProgressEvent()[C:\projects\as3-commons\as3-commons-async\src\main\actionscript\org\as3commons\async\operation\impl\AbstractProgressOperation.as:135]
at org.as3commons.async.command.impl::CompositeCommand/onCommandResult()[C:\projects\as3-commons\as3-commons-async\src\main\actionscript\org\as3commons\async\command\impl\CompositeCommand.as:287]
at flash.events::EventDispatcher/dispatchEventFunction()
at flash.events::EventDispatcher/dispatchEvent()
at org.as3commons.async.operation.impl::AbstractOperation/dispatchCompleteEvent()[C:\projects\as3-commons\as3-commons-async\src\main\actionscript\org\as3commons\async\operation\impl\AbstractOperation.as:152]
looking at the AbstractProgressOperation code in the async lib at the given line, there's nothing really done there:
/**
* Convenience method for dispatching a <code>OperationEvent.PROGRESS</code> event.
* #return true if the event was dispatched; false if not
*/
protected function dispatchProgressEvent():void {
dispatchEvent(OperationEvent.createProgressEvent(this));
}
I can rule out my code as the culprit as well, as all parts of it are working seperately and are tested in many other aspects. Plus I don't really do anything either right now other than calling execute() on the command and fire an complete event.
For debugging I added some heavy trace() calls, which assumingly causes a slight delay, and voilà, it now crashes some lines further down in the code, still with "undefined" pointing a line in the code which is very unsuspicious. (once it was a call to invalidateDisplayList() in a component used for several years now without ever having made any problems)
Did anybody else encounter problems before when a large set of events is fired in very short time? What else can cause this strange "undefined" ?
Thanks as always.
I didn't work on this library but you can delay the event firing by using the magical setTimeout as following:
protected function dispatchProgressEvent():void {
setTimeout(function():void
{
dispatchEvent(OperationEvent.createProgressEvent(this));
}, 0);
}
This will delay the execution of the dispatchEvent until all current operations processed.
I have worked on the as3commons-async library. I don't have a definitive answer for you, I'm afraid, just my suspicion that this error isn't necessarily related to as3-async.
You describe similar weird happenings in other areas of the code base (even in Flex itself), so this kind of smells like either a Flex bug or maybe even a bug in the AIR runtime.
The only thing I can advice here is to create a test application that fires events in a similar fashion and speed (so, without using as3-async) to see whether you can re-create the errors.
If it does turn out to be a runtime issue, at least you'll have a solid testcase to send to Adobe.
I apologize for not being able to help you out concretely.
cheers,
Roland
An existing (though incomplete) FLEX3 project was given to us to finish (always a nightmare).
It is quite small but highly abstracted (contains well over 150 files to support only about 10 page views). I'm attempting to trace a single mouseclick event through this maze.
Is there a way to print out an actionscript trace and/or component flow using the debugger (or any other tool that anyone knows of)?
The flash.txt file appears worthless since it doesn't contain ActionScript calls and/or component flows.
Thanks
This will print your execution graph:
Trace.setLevel(Trace.METHODS, Trace.LISTENER);
Trace.setListener(handleMethods);
function handleMethods(fqcn:String, lineNumber:uint, methodName:String, methodArguments:String):void
{
trace(methodName);
}
Oof. Yeah, always.
The Profiler might give you useful information, but you need to pay for FlexBuilder Pro to get it, if you don't already have it. I'm not real handy with the Profiler, so I may be off base with that advice. It would be worth checking into, though, if you are already familiar with other profiling tools.
I would probably just start looking at every point that .addEventListener(MouseEvent.CLICK occurs in the code - and .addEventListener("click", just in case the previous developer chose not to use the constant, for some reason.
Obviously, that could show up a lot in 150 files, but that's how I would go about it.
I would also look at any custom events that could get into the mix. Because maybe the CLICK event is handled at some point and the handler dispatches a custom event. And maybe the handler for that custom event dispatches another custom event. Or dispatches a MouseEvent.CLICK event, etc.
Hope that helps. Good luck...
Check out
http://jpauclair.net/2010/02/10/mmcfg-treasure/
esp.
AS3Trace = 1|0
This one is also very useful for
debugging It trace every single call
to any function that is being called
in the SWF at runtime! It’s like
expending the StackTrace to the full
software run time.
And many more.