I have an application which does some simulation, and renders the result. Because the render can sometimes be very slow, I separated it into another thread, and the main thread calls gtk_widget_queue_draw once it's ready. If it's not finished drawing yet, the extra requests get discarded (since queue_draw only invalidates it, and it's impossible to be "more" invalid).
The result is that with large complicated systems, simulation maxes out a thread, and render maxes out another thread, and everything works.
I just ran into a different problem, and I don't see why it's happening: A sufficiently simple simulation and render (6 5-point lines) causes it to break.
The first few (I've seen everywhere from around 60 to 400) steps render fine (in a fraction of a second), until one step renders twice. After that, it ignores the queue_draw, until I do something like drag a window over the render window, after which it restarts (until it breaks again).
If I artificially slow down the requests (usleep(10000) is around enough), this does not happen.
This is a completely unacceptable solution however, because the process of displaying is not allowed to interfere with the normal simulation thread (No delays, no mutexes, etc. etc.). I need a solution that makes the render thread do "as well as possible", given that it is working with volatile data. It does not have to be perfectly accurate--I really don't care if a frame renders a little wrong (half of frame i, half of i+1 is fine), as long as it does render.
Why is this happening, and how do I fix it?
You are having a race condition.
Since GTK3.6, you need to call gtk_widget_queue_draw like this:
g_idle_add((GSourceFunc)gtk_widget_queue_draw,(void*)window);
or like this:
gdk_threads_add_idle((GSourceFunc)gtk_widget_queue_draw,(void*)window);
where window is the GtkWidget* you want to draw.
Use the gdk_threads_add_idle if you're not sure whether libraries or code used by your app use the deprecated (since 3.6) gdk_threads_enter and gdk_threads_leave functions.
See: https://developer.gnome.org/gdk3/stable/gdk3-Threads.html#gdk3-Threads.description
Before GTK3.6, gdk_threads_enter and gdk_threads_leave had to be used to acquire the lock for GTK calls.
Did you locked UI calls in the threads with gdk_threads_enter/gdk_threads_leave ?
Maybe adding a code sample would help too...
Related
I need to check if an element is appearing after refreshing a page continuously, cause it takes a while for the changes to be reflected and the element to appear in that page.
Is there any built in method in selenium using Ruby as the programming language ?
Just to confirm, it sounds like the page does not dynamically update once the content is available, so you have to wait until that is true, and then manual refresh, right?
I don't know of anything built into selenium to handle this. It feels like it might even be a symptom of a UI that needs a little more design work (pardon my critique). If the user is experiencing the same thing as the test -- kicking off an action, waiting some unspecified period of time, and then manually refreshing to see the results -- that's a kind of lousy user experience. If that's a bad assumption, and there IS feedback (e.g. a spinner), then your best option will be to conditionally wait for the spinner to appear and then disappear, and then refresh a single time.
If there's really no visible feedback, then you still have a couple of options:
Easy: Hardcode a sleep that's longer than the operation will ever take to complete, and refresh once.
Medium: In a loop, sleep for a constant delay, refresh, repeat until some timeout.
Hard: If the delay required varies widely (sometimes seconds, sometimes minutes), you might consider an exponential back off solution, that sleeps for increasingly longer delays each iteration, before ultimately timing out. The upside is that you're not frantically refreshing dozens of times, the downside is that your delay might be unnecessarily long, if the content arrives just after the next big delay begins.
You can use wait method for the element to be available.
If you need to refresh the page continuously just make sure to wait after each refresh.
the timeline functionality in moblin clutter is used to do a callback every given milliseconds.although it is emitting signals lot faster(every 1ms or so). Why does this happen?
ClutterTimeline * clutter_timeline_new(guint msecs);
you should not be using a Timeline to get a notification (and execute code) that N amount of milliseconds have elapsed. ClutterTimeline is a object that is tied to the redraw cycle of the UI. timelines are advanced every time Clutter redraws a frame, to let the application code know that it has to update its state.
if you just need to have your code called after an interval, use g_timeout_add() instead; this function is tied only to the main loop, and not to the redraw cycle. there are other considerations to be taken care of when using a timeout, so you should read the documentation:
http://developer.gnome.org/glib/stable/glib-The-Main-Event-Loop.html#g-timeout-add
strictly speaking, if you're using Moblin, you're probably using a very old version of Clutter, so there may be bugs as well; not that I know of bugs where the ClutterTimeline::new-frame signal is called every millisecond, mind you.
Is there a (or, do you have your own) preferred way to do background processing in slices on the UI thread in Windows Forms? Like OnIdle() in MFC?
In native Windows programming you could roll your own message loop to do this, but Application.Run() doesn't give us access to the message loop.
The Application.Idle event gives us no way to trigger it repeatedly.
I guess you could call native PostMessage() with P/Invoke (since there's no managed version) to post yourself a private "WM_IDLE" message, and override WndProc() to catch it. I don't know how this would get along with Application.Run().
So far I've used a short Timer for this, but I'm afraid I may be losing cycles sleeping, especially since the actual Timer resolution is coarser than the nominal 1 ms minimum.
The best option I've seen is to use a modified version of the Managed DirectX Render Loop designed by Tom Miller. By adding a call to Thread.Sleep() inside the render loop, you can pull your CPU usage down dramatically.
This does require a P/Invoke call to track that the application is still idle, but as long as it's idle, you can make a "timer" that fires continuously during the idle phases, and use that to do your processing.
That being said, on modern systems, you almost always have extra cores. I would suggest just doing the processing on a true background thread.
I thought of my own possible answer, inspired by Reed's talk of multithreading. I may have a way to retrigger Application.Idle:
Create a hidden form, let's call it formRetrigger.
In Application.Idle, launch my Retrigger() method on a thread pool thread.
Retrigger() calls formRetrigger.InvokeOnClick() (or any of the other "Control.Invoke" methods). I expect this to launch another message through Application's queue, causing Idle to get triggered again.
I am designing an application which has the potential to hang while waiting for data from servers (either Database or internet) the problem is that I don't know how best to cope with the multitude of different places things may take time.
I am happy to display a 'loading' dialog to the user while access is happening but ideally I don't want this to flick up and disappear for short running operations.
Microsoft word appears to handle this quite nicely, as if you click a button and the operation takes a long time, after a few seconds you get a 'working..' dialog. The operation is still synchronous and you can't interrupt the operation. However if the same operation happens quickly you obviously don't get the dialog.
I am happy(ish) to devise some generic background worker thread handler and 99% of my data processing is already done in static atomic methods, but I would like to go best practice on this one if I can.
If anyone has patterns, code or suggestions I welcome them all
Cheers
I would definitely think asynchronously using a pattern with 2 events. The first "event" is that you actually got your data from wherever/whenever you had to wait for it. The second event is a delay timer. If you get your data before this timer pops, all is well and good. If not, THEN you pop up your "I'm busy" and allow them to cancel the request. Usually cancel just mean "ignore" when you finally get the response.
Microsoft word appears to handle this quite nicely, as if you click a button and the operation takes a long time, after a few seconds you get a 'working..' dialog. The operation is still synchronous and you can't interrupt the operation. However if the same operation happens quickly you obviously don't get the dialog.
If this is the behavior your want...
You could handle this, fairly easily, by wrapping a class around BackgroundWorker. Just time the start of the DoWork event, and the time to the first progress report. If a certain amount of time passes, you could show your dialog - otherwise, block (since it's a short process).
That being said, any time you're doing work that can be processed asynchronously, I'd recommend doing it that way. It's much nicer to never block your UI for a noticable interval, even if it's short. This becomes much simpler in .NET 4 (or 3.5 with Rx framework) by using the task parallel library.
Ideally you should be running any IO or non-UI processing either in a background thread or asynchronously to avoid locking up the UI.
This is an odd one. I am making a app that is kind of a game, and I wanted to have a shooting starburst effect. I made it one evening and it all worked well, until I noticed that my browser was eating over 300 megs of ram, eating 1 meg every 5 seconds, mainly when the starburst would happen.
Here is an example stripped down to just the starburst:
http://www.sizzln.com/example.htm
First thought, I am not removing the objects or still have references somewhere. I am placing each generated star into a Canvas, but I am removing old starts every 3 seconds. I do have a lot of DoubleAnimations as well, but I even have a callback to set everything to null.
Here is the weird part, if I convert it to WPF it doesnt happen, if I run it inside of Silverlight Spy 3, it doenst happen. If I take a Heap Dump using WinDbg and SOS.dll, it reports that it should only be using between 1.8 and 3 MBs of ram.
I have the GC running every 3 seconds to cleanup, but it never has any effect. I can see in the heapdump that many objects are now deleted, and I always get back to 1.8 meg or so after a GC, but the memory shown in Task Manager just keeps going up.
I dont know what to do, I think I am carefully removing the objects unless my Heap is not being honest.
Are you running Vista or Win7? It sounds like the OS is not reclaiming memory, as it shouldn't unless it needs to.
It may also be that the Silverlight GC doesn't free its buffers, on the assumption that the memory may need to be reallocated soon.
In either case, it doesn't sound like anything to worry about, as long as the profiler says your program only uses 1.8MB after the GC runs.
I just briefly looked over your code. You have a lot of places where you hook into events (+=), but never unhook (-=). These are hard references and therefore won't ever be collected if they are ultimately connected to a root object.
OK I am going to sorta answer my own question. Silveright doesn't have the handy "BeginAnimation" method, so I found online a quick way to add an extension to do basically the same thing, it did this by creating a storyboard and starting it.
However, it just stayed there, I dont exactly know what it was being connected to either. Calling Stop() on it after it finishes fixed my memory issue.
One odd side effect is I have to be careful when I call the stop method, when creating so many storyboards it seemed to get a bit confused and it would cause some of the objects to reappear, even after they were removed from the control.