I'm plotting two Line Graphs using the Oxyplot Library in a WPF application, which works pretty well. There are a maximum of 8 lines, but for the sake of the test, I'm only using 2.
The program allows the user to choose the refresh rate of the data, which is also used to refresh both Plots. All works as it should, unless when the user choose a Refresh rate under 1 second.
Some seconds after the refresh has been set to under 1 sec, the Plot just vanishes and its area turns blank. A weird fact tho, the Tracker still works if I can find the right spot in the line, i.e. the points of the graph are still there, but it's not been shown anymore. It happens first with one Graph, than some time later the second Graph also turns into a deep white area.
I wonder, is there any limitation for the refresh rate for Line Graphs of the Oxyplot library? I mean, does it use some buffer or cache memory that is probably been blown by the high refresh rate? And yes, I would need it to refresh this fast in some cases.
Related
In real-time games, there is always a game loop that runs every few milliseconds, updates the game with new data and repaints the entire screen.
Is this something that is seen in other types of applications, other than games? A 'constant-update-loop'?
For example, imagine an application like MSPaint. The user can draw lines on the screen with the mouse. The line that is being drawn is displayed on the screen as it is being drawn.
Please imagine this line is actually made of a lot of smaller lines, each 2 pixels long. It would make sense to store each of these small lines in a List.
But as I said, the line that is being drawn (the large line, made out of lots of small lines) is displayed as it is being drawn. This means that a repaint of the screen would be necessary to display the new small line that was added the previous moment.
But - please correct me if I'm mistaken - it would be difficult to repaint only the specific part of the screen where the new small line was drawn. If so, a repaint of the entire screen would be necessary.
Thus it would make sense to use an 'update loop' to constantly repaint the entire screen, and constantly iterate over the list of lines and draw these lines over and over again - like in games.
Is this approach existent in non-game applications, and specifically in 'drawing' applications?
Thanks
Essentially you do have a loop in all applications, and games. How that is implemented depends on the system and desire of your application/game. I will loosely base my response toward the Windows system, if only because you mention MS Paint
MS Paint will likely NOT contain a List of lines like you are mentioning, instead it will edit the bitmap image directly each frame, coloring the required pixels immediately and then drawing it. In this situation drawing small portions of the image/application is as easy as telling "this part" of the image to draw itself "over there". So as you move the pencil tool around the pixels turn black and get drawn.
MS Paint and most applications will use a primary loop that WAITS for the next event, meaning, it will allow the operating system (Windows) to not process anything until it has messages/events to process (such as: Mouse Move, Button Press, Redraw, etc).
For a game, it needs to be a little differently. A game (typically) doesn't want the operating system to WAIT for the next message/event before processing continues. Instead here you Poll the operating system to check if there are messages to be handled, and if so handle them, if not continue with the game creating a single frame (perform an Update and Render/Draw the scene.)
MS Paint doesn't need to keep updating and drawing when the user is not interacting, and this is preferred for applications because constantly updating/drawing uses a lot of system resources and if every application did this, you wouldn't have 30 things running at the same time like you probably do now.
This is more of a conceptual/implementation question, rather than a specific language problem.
Does anybody have any insight into cursor movement recording?
It's very easy to get a cursor's current position, but how would you go about recording the path followed by the cursor?
(To the degree of detail where it could be plotted graphically without ambiguity as to the path taken)
I imagine you could record the cursor's current position repeatedly after a small duration, logging it all to make a list of chronologically visited coordinates,
but I'm not sure how frequent (or feasible) the recording should take place; every 10 ms?
I've not even encountered a method of sleeping for such short durations to the nescessary precision!
I'm concerned also about the performance of the sleeping and recording during intense CPU usage; when the user is using the mouse to interact with intensive software.
I'm not even entirely sure where the cursor is really moving.
If I sweep my cursor across the screen, has the computer (somewhere internally) acknowledged that I crossed all those pixels,
or has my mouse really told it "I was there, now I'm over here, now I'm there".
I do also seek a method of differentiating between fast and slow movement, but for now, I can just observe the plot spacing on a graph of the visited coordinates.
Does anybody have any insight into this?
Any potential pitfalls; are my concerns legitimate?
Am I going the wrong way about this?
(As is observable, I really need some guidance in the matter)
Thanks!
It's far easier to log the mouse movements within the same application - just log something on every WM_MOUSEMOVE message. You will get a message periodically updating the mouse pointer location. You will not get a WM_MOUSEMOVE message for every pixel the mouse crosses, but it will jump depending on how fast you move the mouse and how busy the system is.
Logging mouse movements in some other application is going to be slightly more involved. If you have written both the logger and the application being logged, then you can handle WM_MOUSEMOVE in the application being logged, and send a corresponding message to your logger application. Your choice of IPC; a simple SendMessage() might be sufficient.
Logging mouse movements across the whole system is a totally different problem. You may have to hook in at somewhere closer to the driver level.
I just thought of another approach - the CBT (Computer-Based Training) hooks are designed to provide exactly this sort of information across applications. I've never used these though, so you'll have to do more investigation.
In my WPF app I have a control representing a pack of 20 cards (each about 150x80 px) that fan out in an arc, so they're all slightly overlapping in the centre of the arc. When the control is added there's an animation to fan them out.
After that, the fan/control can be moved around, and when the user hovers over a card it expands and then goes back to normal size when they move off it.
This all works fine, but has a noticeable effect on performance- everything is very jerky, presumably because when other things move all the overlapping stuff and transforms in the control are being constantly recalculated/redrawn.
Any suggestions for how I can improve performance while still keeping individual cards in the fan responsive?
To find the source of the slowdown you need to profile.
Try to find out whether or not WPF is switching back to software rendering or not.
After that try to run on a different computer with other (better) hardware/graphics card.
If it doesn't get any better there might be errors in your app.
I have a few fairly simple animations (moving text around, moving ellipses etc.) and running in full screen (1920x1080 minus the task bar) the WPF Performance Suite reports a good framerate around 50 FPS throughout the animation. Dirty Rect Addition is somewhere around 300 rect/s, the SW frames are between 0 and 4 and the HW frames are between 3 and 5. Video memory usage is around 80 MB.
Problem is that the animations stutters every other half second. It is definitely not fluid :-(
My machine is a new Dell laptop XPS 15 with the GeForce GT 435 with 2GB memory. - The drivers are up to date. (The same behavior occurs on my netbook (in full screen) as well so I don't think it is hardware related.)
If I make the window smaller the stutter goes away.
The stutter occurs with the simplest of animations - even with just a couple of elements but adding more elements certainly makes it more noticeable.
How can I find out what causes this stutter?
When I think of it, I have not actually seen any WPF animations which run smoothly in full screen. Is this even possible?
Have you tried to set a lower "max frame rate" to the animation?
<Storyboard Timeline.DesiredFrameRate="10">
<!-- ....blah blah blah -->
</Storyboard>
If your animation is causing massive recalculation of child or parent elements, changing the DesiredFrameRate will have a cascading effect on the number of calculations made by the system.
Also, check out the "Remarks" section of this link. It explains why/when you should use it.
If setting a lower frame rate fixes your stuttering, then you need to consider simplifying your XAML to limit the amount of recalculation needed at every frame of your animation (limiting the number of child or parent objects resized - or affected in any way - by every frames/changes made by the animation.
You might want to also check out the "WPF Performance Suite". It is an awesome set of tools to determine what exactly is going on in your WPF app, seeing which parts of your window are being repainted and when, and the CPU usage of each of your XAML elements!
Hope this helps!
Patrick,
I have no answers. All I can do is provide some solidarity. I'm trying to animate an ItemsControl. The concept is pretty simple, really. I've got a ListView and in the ListView I have a GridView. I want the items in the GridView to to smoothly go from one row to another row as the underlying list is sorted so that, for example, a sorted list will stay sorted as the values in the list change.
I've noticed this: animation on moderately complex controls is a CPU hog. The stuttering I'm pretty sure is simply related to the CPU being maxed out (I noticed you didn't provide the CPU graph on your dump above). Keep the CPU around 50% and the animation appears smooth, above 75% and you get these stutters.
Still working on the problem, but I think it goes deeper than my code.
Don
I had a similar issue where it was stuttering, nothing really major it just looked like little stutters here and there while I ran the program. On a hunch, I shut down Google Chrome while it was running and that fixed it,the scrolling became completely smooth...
So my advice would be if you have any internet browsers open check to see if closing them out fixes the problem.
I've created a WPF control (inheriting from FrameworkElement) that displays a tiled graphic that can be panned. Each tile is 256x256 pixels at 24bpp. I've overridden OnRender. There, I load any new tiles (as BitmapFrame), then draw all visible tiles using drawingContext.DrawImage.
Now, whenever there are more than a handful new tiles per render cycle, the framerate drops from 60fps to zero for about a second. This is not caused by loading the images (which takes in the order of milliseconds), nor by DrawImage (which takes no time at all, as it merely fills some intermediate render data structure).
My guess is that the render thread itself chokes whenever it gets a large number (~20) of new BitmapSource instances (that is, ones it had not already cached). Either it spends a lot of time converting them to some internal DirectX-compatible format or it might be a caching issue. It cannot be running out of video RAM; Perforator shows peaks at below 60MB, I have 256MB. Also, Perforator says all render targets are hardware-accelerated, so that can't be it, either.
Any insights would be appreciated!
Thanks in advance
Daniel
#RandomEngy:
BitmapScalingMode.LowQuality reduced the problem a little, but did not get rid of it. I am already loading tiles at the intended resolution. And it can't be the graphics driver, which is up-to-date (Nvidia).
I'm a little surprised to learn that scaling takes that much time. The way I understood it, a bitmap (regardless of its size) is just loaded as a Direct3D texture and then hardware-scaled. As a matter of fact, once the bitmap has been rendered for the first time, I can change its rotation and scale without any further freezes.
It's not just with a large number of images. Just one large image is enough to hold up rendering until it has been loaded in, and that can be quite noticable when your image dimensions start getting up in the thousands.
I do agree with you that it's probably the render thread: I did a test and the UI thread was still happily dispatching messages while this render delay was taking place from trying to display a fully pre-cached BitmapImage.
It must be doing some sort of conversion or preparation on the image, like you were speculating. I've tried to mitigate this in my app by "rendering" but hiding the image, then revealing it when I need to show it. However this is less than ideal because the rendering freezes happen anyway.
(Edit)
Some followup: After a discussion on the MS WPF alias I found what was causing the delays. On my Server 2008 machine it was a combination of old video drivers that don't support the new WDDM driver model and a delay for resizing the image.
If the source image size is different from the display size, that will delay the render thread before the image shows up. By default an image is set to the highest quality, but you can change the scaling options for rendering by calling RenderOptions.SetBitmapScalingMode(uiImage, BitmapScalingMode.LowQuality); . Once I did that, the mysterious freeze before displaying an image went away. An alternative, if you don't like the quality drop in scaling, is to load the BitmapImage with DecodePixelWidth/Height equal to the size it will be displayed at. Then if you load the BitmapImage on a background thread, you should have no delay in displaying it.
Also try these;
/* ivis is declared in XAML <Image x:Name="iVis" UseLayoutRounding="True" SnapsToDevicePixels="True" /> */
iVis.Stretch = Stretch.None;
RenderOptions.SetBitmapScalingMode(iVis, BitmapScalingMode.NearestNeighbor);
RenderOptions.SetEdgeMode(iVis, EdgeMode.Aliased);
VisualBitmapScalingMode = BitmapScalingMode.NearestNeighbor;
iVis.Source = **** your bitmap source ****
I was having some trouble with performance when using a huge amount of "A" channel color's, waiting until after the image had rendered to scale it worked much better for me.
Also, as you said your using a tiled graphic?
You would usually use a TileBrush to simply set as the Brush on your FrameworkElement. If you are animating them or adding new ones dynamically, you could generate your brushes then apply them to your object as you go manually too, be sure to Freeze them if you can. Also, VisualBitmapScalingMode is a property of any Visual.