I am running a Helix viewport and am catching a mousewheeled event with previewmousewheel to run a method. When debugging some changes I made to my methods I found out that when I set a breakpoint (anywhere between the catching of the mousewheeledevent and the subsequent applying of the zoom in the viewport) the amount of zoom from one detent of the mousewheel will increase continuously in proportion to the amount of time the program has been paused (basically the amount of time elapsed from the mousewheeledevent and the applying of the delta to the viewport). This makes debugging my changes the way I normally do seem not possible, though of course I can work around this.
The real problem is that now I realize that the zoom is completely erratic in this way, because some operations take longer than others between the event and the setting of the viewport, depending on what I'm doing.
This seems like a completely haphazard thing to have going on when I'm trying to make changes to a camera and completely control the camera behavior based on details specific to my program.
Is there any way to disable this from happening or mitigate it almost entirely?
The following code is a snippet from my program that seems to be the main driver of the issue, but I'm not sure I can just remove this method of keeping time in the program, because we definitely need an asynchronous timekeeper as far as I know.
private async Task DoWorkAsyncInfiniteLoop()
{
while (true)
{
if (Run)
{
Time.timeElapsed += Time.runSpeed;
Time.simTime += Time.runSpeed;
updateAll();
}
// don't run again for at least 200 milliseconds
await Task.Delay(Time.interval);
}
}
perhaps there is some lines I can add that will basically allow me to apply the zoom to the viewport without waiting for the await Task.Delay(Time.interval) line to run?
I must admit I'm not too clear on how that code works, but I do know that it stops at the await Task.Delay line before finally i hit "step into" (F11) one more time and it somehow just applies the monstrous zoom that was not wanted, without my seeing any code after that being run.
Any workarounds?
Try to set IsInertiaEnabled = false on viewport
Related
I need the application idle time in my software. For that reason, I made a helper class ApplicationIdleHelper which implements the IMessageFilter interface.
This works fine and if my application is in idle for some time, I'm showing a DevExpress WaitForm using this line of code:
SplashScreenManager.ShowForm(typeof(WaitForm));
In this WaitForm I show the user some information about what's being done in the background. If the user moves the mouse or presses some keys I close the WaitForm like this:
SplashScreenManager.CloseForm();
Here's the problem explained in steps:
Mouse cursor is on the form.
User doesn't do anything for some time -> idle time -> so I show the WaitForm.
Now I get a MouseMove message in my PreFilterMessage method? BUT WHY? Mouse didn't move. No keys pressed? Because I get a MouseMove message my application thinks, the user did some input and automatically closes the WaitForm.
Same behavior if I close the WaitForm.
Here's a sample application, so you should be able to reproduce the behavior:
https://drive.google.com/file/d/0BxabrokJG-OWV3FLV2hNNVk5NjQ/view?usp=sharing
The DevExpress documentation says:
Wait Forms and Splash Screens are displayed by a Splash Screen Manager
in a separate thread.
Maybe this has something to do with that behavior?
Hope somebody can explain me, why I geht a MouseMove message in my PreFilterMessage function, after showing or closing the WaitForm.
Thank you in advance.
The most likely cause of this is that the mouse is sensitive to environmental noise. It's entirely possible for a mouse to experience a little bit of jitter that causes it to report very small movements, which ultimately work out to zero change in position. Alternatively, and this isn't verified, Windows or some other software on the system could be generating extra mouse move messages to make sure that everyone stays in sync with the current mouse position.
Either way, the most stable solution is to decide on an amount of motion you consider "real" (see threshold below), and then:
Capture the mouse position when you're going to sleep.
Every time you get a WM_MOUSEMOVE message (or a MouseMove event) calculate the amount of that motion, as in:
Point cached; // from when you went to sleep
Point current; // determined from the window message/event
double move = Math.Sqrt(Math.Pow(cached.X - current.X, 2) +
Math.Pow(cached.Y - current.Y, 2))
if (move > threshold)
{
// Wake up
}
else
{
// Ignore and optionally update the cached position
// in case the mouse is slowly drifting
}
(Note that you don't necessarily need to calculate the real distance that way, you could just use ΔX+ΔY)
Whenever you're dealing with hardware, you need to be ready for it to send you updates that you aren't expecting. Pressing a button for example, can cause the physical contact to bounce, which causes multiple press/break signals at the electrical level. Most of the time, the hardware is designed to filter the noise, but sometimes this seeps through.
My question might seem silly to you, but I realized that moving my applications form makes the code inside it run slower. E.g. when I load a bitmap image and apply some image editing algorithms on it, it takes about 22 secs for the whole process to finish. But if I move the form during execution, it adds some 3-4 extra seconds to the elapsed time. I was able to spot the delay using a Stopwatch. So how can I get around this behaviour, if possible at all?
This is just an hypothesis that requires your investigation, as you didn't post any code and thus it is impossible to really know what is going on.
Most probably you move the boundaries of the image outside the screen. When you move in again, the windowing engine will do some draw calls on those rectangles to be redrawn. The same happens on resize when you enlarge but not when you shrink the window.
If this is the case, then you will not experience any extra draw calls as long as you don't cover/uncover areas of the image.
So this is not an answer but in your place I would override the Paint() method and log how many excess calls are made. Based on this, I'd search for a solution, such as suppress those calls like this:
public override void Paint()
{
if (algorithmRunning)
{
return; // suppress any further computations
}
base.Paint(); // do actual redraws
}
This code is just an example, you'll have to fix it according to the MSDN documentation.
What you should NOT do is just hook into the OnPaint() event, because then you'll still have the actual Paint() method called.
OK so we have a program where we want to animate the controls on a WinForm and then then resume subsequent operations of the remaining block of code. Here is the sample code.
The function is on the WinForm, which is running on main thread presumably
Private void DoThisWork();
{
do some work here
animateControls()
//<NEED TO PAUSE HERE WHILE THE GUI ANIMATES AND UPDATES DISPLAYING THE ANIMATION OF THE CONTROL>
//Tried Option 1: thread.sleep. When we do this the main thread blocks and the animation is //not seen. The control is directly painted at x1,y1 and thats it, the intermediate rendering is not seen
// Tried Option 2: Application.DoEvents. This works very well except that the CPU maxes out and the animation then appears very jittery
continue doing remaining work // must execute only after animateControls() completes the animation part.
}
Now, animateControls() is simply a function that is on a timer and moves a control from point (x,y) to (x1,y1) and this takes about 3 seconds.
SuspendLayout and ResumeLayout dont force GUI update because thread.sleep caused the main thread to block so everything is virtually at a standstill.
Using a different thread to animate the GUI does not seem to help because I still need for the entire animation to complete.
Also, I cannot add anything in the animation code because it is called from multiple functions and therefore is used as a common function.
Your are going down the wrong path. Put your work to do on a seperate thread and let your UI Thread do your animation till the work thread is finished.
The BackgroundWorker class might come in handy. http://msdn.microsoft.com/en-us/library/system.componentmodel.backgroundworker.aspx
Ok, so I found some rather weird behaviour while messing around with the WPF ProgressBar control. This control is located in a column of a ListView control and the general situation differs little from this question & answer in its essence.
I bind Progressbar to a class by means of several properties (Min, Max, Value), all OneWay Bindings obviously. This other class is updated from another thread and regularly uses the INotifyPropertyChanged interface to let the ProgressBar know the status is progressing. And this all works just great!
But here is where it gets odd. My ProgressBar loses its glow.. right upto the moment it reaches the Max (=100%) value. Then it suddenly starts pulsing its white glowy stuff all over the green bar, and this is very annoying. I am showing progress with a reason, and the lack of a pulse is actually pretty distracting once you start to notice it not being there.
Thus, I set off to debug. I found that with Thread.Sleep(1000) in my threads processing, it still hid the glow, but if I bump it to Thread.Sleep(1500) the glow comes back at all times with a crazy vigour. After that, I tried translating my progress units to smaller numbers so the integer values would take longer to change. Min 0, Max 100 still has the lack of the glow. Min 0, Max 10 had the glow come back in its full vigor. In all cases, it is the same amount of work and time spent to reach 100%, but it is a very visible binary YES/NO effect with regards to the glow showing. The only thing I have not tested is whether it also happens when the ProgressBar is not placed inside of this ListView control.
I know myself well enough that I can't make sense of the deep WPF innards of the (XAML involved with the) ProgressBar control. So I was hoping anyone here knows whether this is a known bug, something they stumbled into, or something they might even know how to work around/fix.
My machine runs Windows 7, and I'm developing in VS2010 targeting .NET Framework 4 Client Profile.
I would take a guess and say that you lose the glow because you are updating your progress bar to often. Every time you set a new value the progress bar restarts its glowing animation (I think - I haven't tested this, I'm writing off the top of my head).
It seems that you have perhaps thought of the same thing and tried to work around it, but I'm not sure you have fully exhausted all possibilities:
Try creating a check that if (progressbar.Value == newValue) don't do progressbar.Value = newValue;
Progressbar should be using Decimals for Min, Max, Value. Make sure you don't do updates for every decimal point, eg. - 10,1; 10,2; 10,3; etc... (use progressbar.Value = (int)newValue;)
Try setting the progressbar value in bigger increments, instead of increment = 1, use increment = 10;
You could try taking a progressbar outside of ListView, maybe there is a rendering bug with progressbar being inside it.
PS! If you update your progressbar very rapidly, then it is OK for the glow animation not to run. Remember that the glow animiation's purpose is only to show that the application is still running (machine hasn't frozen), despite the fact that the progress(bar) hasn't moved.
If the progress is moving quickly, then that on its own is a visual effect for the user, so there is no need to have the glow animation at that moment...
I have a C# .NET application with which I've created a custom image display control. Each image display represents its own display context and draws the image using glDrawPixels (Yes I know it would be better to use textures, I plan to in the futures but this app is already too far along and my time is limited).
I am now trying to have both images pan simultaneously. That is, when one image is moved down ten pixels, the second image moves down ten pixels. Like so:
imageOne.YPan -= 10;
imageTwo.YPan -= 10;
imageOne.Invalidate(); //This forces a redraw.
imageTwo.Invalidate(); //This forces a redraw.
Alright so here is the problem I am having. Only one of the images displays is redrawing. If I place a pause in between the two Invalidate calls and make the pause duration at least 110 milliseconds both will redraw, but not simultaneously. So it looks as if the second image is always trying to catch up to the first. Plus, a 110 millisecond pause slows down the motion too much.
I have tried placing the updating and invalidating of each image in its own thread but this did not help.
At the beginning of drawing I make the appropriate context is current, and at the end I am calling swapbuffers(). I tried adding a glFinish to the end of the draw function, but there was no change.
Could it be that its the graphics card that is the problem? I am stuck using an integrated gpu that only has openGL 1.4.
Hopefully, I have provided enough detail that the answer to my problem can be found.
Its difficult telling what's wrong with what you do since you give so little detail. Here are some pointers which may help.
- before doing something in a context, make sure you make it the current one. If you want to pan two contexts, make the first one current, pan it and then make the second one current and pan it. These is no real reason why this should not work.
- If it looks like there is a timing problem, adding glFinish() at strategic places may help weed the problem out
- As should always be done, on occasions call glError() and see that everything went well.
- I'm not sure how this is done in the framework you're talking about but you should make sure that both contexts get a swapBuffers() call for every frame.
Invalidate doesn't force an immediate redraw. It marks the window invalid, and when the message queue runs out of other messages, a paint message will be created and processed. But that won't happen until you finish processing the current message and return to the main message loop, and it may be delayed even more than that.
Generally OpenGL animation is an exception to the rule of doing all drawing inside Control.OnPaint (or in a handler for the Control.Paint event).