JavaFX with a crazy frame rate?
I was giving a demo of different JavaFX animation options today. However, on the machine I used for the demo, the AnimationTimer behaves very strangely.
As I understand it, JavaFX is supposed to aim for a rate of around 60FPS, and the "handle" method of the animation timer is called before each frame. However, on this machine, the speed is immensely faster. I ran the diagnostic program from the accepted answer of this StackOverflow post, and it reports more than 1000FPS.
Environment: Ubuntu 16.04, Java 1.8.0_131
Any ideas what could be causing this problem and/or how to control it?
Related
I am writing a big project in Julia at the moment and the only option that I found to debug this code is Debug.jl. It is sooo(!) overwhelming to debug this code without a debugger like the one MATLAB has.
Are there any such debugging tools? I could adopt them even if they are in alpha stage.
Anyone has timeline estimates as to when they are planned to appear?
There is work in progress by Keno Fischer (one of the core Julia developers) on a debugger called Gallium.jl.
This is a very complicated piece of work, due to the nature of Julia as a JIT-compiled language; for example, as one piece, it will include a C++ REPL! As I understand it, there are still some technical issues that prevent it being used, but it will hopefully be available for general consumption "soon".
See this video for a demo, and this discussion on the julia-dev mailing list for the latest news.
I have an issue with a Flex application, one that I didn't build, so I can provide all my findings but sorry for any lack of clarity.
There is a Flex app with 7 main views. And there is a memory issue when navigating between views.
All these views were in a ViewStack, but due to some involving 3D objects I assumed it was too much to have it all in the display list. I'm now clearing all children from the stack and adding/removing them when needed. This gave a small performance increase, but still becomes unresponsive with use. The strange thing is, with this and the original method, the CPU climbs with use but eventually levels out somewhere. Now I'm creating new instances of each screen when they are navigated to and setting the previous variable to null. Now it looks like CPU is spiking when the view is created, but leveling out to something much much lower than it was. This felt like progress, but now the available memory keeps climbing where it wasn't before....
My understanding was calling remove child or remove all children would mark the object for deletion when the garbage collector next ran. I can't see any other references to the instance. My code is along the lines of
this.parentApplication.viewstack.removeAllChildren();
this.parentApplication.viewstack.addChild(new HomeScreen);
I have a function for each button to add a new instance like the above.
The only thing I can see and feel silly asking but need confirmation, is each view extends a class called "Screen", this class contains a singleton reference to some core components
this.model = PancakeApplication.instance.model;
this.meaModel = MeaApplication.instance.meaModel;
this.meaModel.addEventListener(ScreenChangeEvent.SCREEN_CHANGE, electedScreenChangeHandler);
Would this trick the garbage collector into thinking it was still needed?
General advice on clearing Objects from the memory pool would awesome!!! I've never needed to analyze the Flash Player in such depth.
SOLVED: I think it's an error with sound drivers, removing all sound and shes purring like a kitten. Works on my machine fine with windows XP, but not on the touch pad the application is crashing on with windows 7 (unsure of the drivers looking into them now).
UPDATE: Now I'm thinking its not the drivers, tried 3 different versions, all with no improvement. I did discover the sound was fading in and out with the TweenLite lib. Doesn't look like there are any memory leaks in TweenLite as it works fine on other machines. Just the use of volumeEasingFunction seems to consume increasing amounts of CPU until it freaks out. It is crappy hardware running windows 7, which doesn't help.
The first thing that comes to mind is you should be setting the use weak reference parameter to true in your event listener. It is the fifth parameter, so in your example:
this.meaModel.addEventListener(ScreenChangeEvent.SCREEN_CHANGE, electedScreenChangeHandler, false, 0, true);
Grant Skinner has a great 3 part series on AS3 Resource Management that would probably help you get a better idea of what to look for. You can find the details about weakly references listeners in part 3 or in a standalone article written before part 3 was posted.
I've given up on actually trying to make it go faster.
My biggest problem is that when I'm inserting the html, the application slows down to a crawl.
I have a progressbar, and I'm calling
QCoreApplication.processEvents()
(I'm using pyqt, by the way)
Can I put insertHtml() into a different thread, so I don't have an unresponsive interface?
How would I go about that? I've looked into QThread and QThreadPool, and I'm not quite sure where to begin.
I had this problem as well, here are a few things I did to make it faster:
TxtBrows->setAcceptRichText(false);
TxtBrows->setContextMenuPolicy(Qt::NoContextMenu);
TxtBrows->setOpenLinks(false);
TxtBrows->setReadOnly(true);
TxtBrows->setUndoRedoEnabled(false);
This should get rid of unneeded overhead.
Also when inserting large amounts of text its good to turn off screen updates:
setUpdatesEnabled(false);
TxtBrows->append(SomeBigHTMLString);
setUpdatesEnabled(true);
This was recommended somewhere in the Qt documentation but I can't find the spot just now.
[Edit]
I stumbled across the spot in the Docs (just in time for them to be outdated by QT5 grinn) http://qt-project.org/doc/qt-4.8/qwidget.html#updatesEnabled-prop
In GUI applications, the main thread
is also called the GUI thread because
it's the only thread that is allowed
to perform GUI-related operations.
-- from the Qt Docs
So, no. Unfortunately you cannot perform that operation in a thread.
Edit: Technically, it is possible. I just wrote a short snippet that did so, however using Qt GUI objects in that way is highly unsafe.
In a kde3 game called ksirtet (a tetris clone) when playing against a computer the human player cannot move the tetris piece left/right. I'm trying to fix it but cannot debug in gdb. After the line "kapp->exec()" gdb stops responding, the game runs and I cannot input any command do gdb to see what's going on. So the question is about debugging kde event loop and any help would be much appreciated.
Generally speaking, you wouldn't want to debug into the event loop unless necessary. That said, you probably want to scatter a sprinkling of breakpoints at places of interest, especially where you think the code should be running after the key press. If you try to step through the event loop code from the beginning, you'll run into problems trying to interact with the program you want to debug.
Additionally, if I recall correctly, you can control-c in gdb, and it will interrupt the program at its current point of execution, and restore control to you. If you really want to see what is going on, try queueing up some events in the game (mash a bunch of keys quickly), then interrupt gdb and step through what the program is doing in response to those events. You'll have to be very quick, though, as the event loop processing on a modern computer is very fast.
In Flex I have a lot of Move effects and AnimateProperty effects.
What I have found in several different places in my code is that far too frequently the effect stops halfway through for no apparent reason.
I have found this in numerous places in my application and it occurs whether or not I am doin something particularly complicated.
Had anybody else experienced this issue?
I have not experienced this problem specifically but you might want to look at the Parallel () and Sequential to make sure that it isn't starting another effect before the first one completes.
This problem may be a byproduct of your app trying to do too much at the same time and the framerate suffering and so it is making your transitions choppy. You can either lengthen the duration of the transition or try to simplify your app to do less. HTH