After I upgraded the android Here SDK to 3.3, Map.setTransformCenter (PointF center) stop working, is that a known issue?
For the use case you describe in the comments, you can try setting the transform center during the OnMapRenderListener#onSizeChanged(...) callback. If it is still unreliable here, perhaps try setting after a short delay following this callback (e.g. repost a runnable to the UI thread which calls setTransformCenter after receiving onSizeChanged callback).
Related
I have been doing an implementation of Conways game of life in PySide [source]. So far it works good until a point in which, under certain conditions I havent figured out yet, the QGraphicsView i use to display the grid (which consists of several QGraphicsRectItems on a QGraphicsScene) suddenly stops being painted continuously. The rest of the window remains responsive and the game thread keeps running and signaling for the ui to update the current generation number. It is only when the window gains focus that the graphicsView updates for about a second and then freezes again.
I find this behavior particularly strange given that i dont override paintEvent, nor call repaint/update methods at all, but what the game thread does is to update every RectItem's brush color according to the status it should have every generation.
Any ideas on what could be causing this?
btw this is on Kubuntu 14.04.3 / KWin 4.11.11 / Qt 4.8.6
Managed to solved it myself! In case someone runs into same issue, all that i needed to do was to schedule an update by calling the update method of the qgraphicsscene every generation (i.e. after operating on the graphicRects from the game thread).
I assume the strange behavior was probably the result of trying to save cpu load, since for the gui thread there was no work to be done!
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 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
I have a 'map' with 100.000 rectangles at the 'itemslayer',
I want to have a dynamic line creation and I draw it at Foreground layer. (That is, I dont want to have a lot of updates... )
The performance is poor, you note the mouse heavy to move, An I think that is an update for every rectangle that this line 'touchs' .
What is for the foregroundlayer then? I thought that It'd let me to draw over a grapchisview without updating the itemlayer...
Maybe it is related with there is not cache for foreground ?
Any idea ? Thanks.
When I was reading the documentation on 4.8.0 and it states this:
Note that QGraphicsView currently supports background caching only (see QGraphicsView::CacheBackground). This function is equivalent to calling update() if any layer but QGraphicsScene::BackgroundLayer is passed.
So, if you just want to update the foreground layer, then it will draw everything anyways, bummer...
I know it's not a answer, but it does confirm what you are seeing.
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