The following picture show that my WPF lines are not as exact like a similar drawing in a non WPF application. So? Where is the problem? antialiasing? or is this a WPF feature? What am I supposed to do?
the below barchart is a simple Shape.Line.
I am not sure I would say "better line quality". Subpixel rendering is a feature in many many cases - actually in most. Financial charts are a special case - but saying WPF lines are bad in general is really an oversimplification. Especially as it points (as some have pointed out) to the usual lack of having read the documentation and learned the technology, as pixel exact rendering was reintroduced some time ago.
What you run into is the main problem that WPF is device independent and allows arbitrary zooming - so everything happens in it's own coordinate system. Which may not run down to exact a pixel. As I said - generally a feature.
Now there are edge cases (like the financial chart you point out nicely) and for that in .NET 3.0 (ages ago, seriously) pixel snapping was made available.
http://msdn.microsoft.com/en-us/library/aa970908(v=vs.85).aspx
has some explanations. It basically works by means of the SnapsToDevicePixels property.
As a matter of fact this is not the first time this question has arrived, as can be seen at - Rendering sharp lines in WPF.
There are a lot of features in WPF and it is quite mandatory to read the documentation. Especially in financial applications - which are not really static, if you deal with real time data. I suggest you do so - you can gain tremendous performance benefits by for example pre-caching parts of the UI in the graphics card memory, which is a simple other trick, easy to do.
Related
I developed a Matrix themed application in Java, and was experimenting with porting to over to C#. However, I found that the latter's DrawString method offered much poorer performance when drawing lots of single characters. Thus I'm hoping there exists one of two possibilities:
There is an alternative method of drawing lots of single characters that is much faster.
There is a way to draw a string with fixed spacing to achieve the same effect. This does not seem likely.
Does anyone know of any way to accomplish either 1 or 2?
Additional information:
I need to be able to draw around 20000 characters 30 times per
second.
The characters can have the same font and size, but colour should be able to be
altered.
The set of characters is finite (letters, numbers, and punctuation).
The location of the characters are along a 2D grid, and do not overlap.
I am not aware of some blazing fast alternative, but using GDI(TextRenderer) instead of GDI+(DrawString) will give a better result. Up to 5-6 times faster.
GDI vs. GDI+ Text Rendering Performance
Another useful article - Rendering fast with GDI+ - What to do and what not to do!
Is there an alternative method of drawing lots of single characters that is much faster?
The Graphics.DrawString methods use GDI+ to draw, which tends to be slower than GDI. GDI is usually hardware accelerated, assuming you have a decent set of graphics drivers installed. The only exception to this is Windows Vista with the Aero theme enabled, but that was fixed in Windows 7. You can switch to GDI instead by calling one of the TextRenderer.DrawText methods instead. Not only is that likely to be somewhat faster than GDI+, there are other advantages to using GDI. The only real disadvantage is that WinForms doesn't support using GDI for printing. But it doesn't sound like that's a concern for you.
Assuming you're targeting only modern versions of Windows that support them, you could also look into some of the new graphics technologies like Direct2D and DirectWrite. For C# wrappers, you might look into the Windows API Code Pack (also see this blog article). OpenGL might also be an option. I haven't used it, but speed is among its claims to fame.
Unfortunately, I'm still not sure if this will be fast enough. A million characters 30 times per second is really an unreasonable amount. No video output device that I know of is even capable of displaying this. Surely there is some type of caching that you could be doing instead. Or perhaps an entirely different design for your application?
Also, keep in mind that drawing into a background buffer (e.g., a bitmap) is often considerably faster than drawing directly onto the display buffer (i.e., the monitor). So you can do all of your drawing onto this background buffer, then periodically blit that to the screen in a single pass. This technique is often known as "double-buffering" (because it uses two buffers), and is a well-known tactic for minimizing flicker. It can also produce speed improvements if you need to draw as quickly as possible, because it allows you to do so while taking into account the inherent limitations of the display output.
There is a way to draw a string with fixed spacing to achieve the same effect. This does not seem likely.
Drawing with fixed spacing is not going to increase the speed over using proportional spacing.
There are a few "tricks of the trade" to keep in mind when you're writing particularly critical drawing code, but I seriously doubt that these will be of much use to you, given how high you're expectations are. They're more for tuning an algorithm, not increasing its performance by multiple orders of magnitude.
We're going to do some experiments on perceptual thresholds and want to show an image for a very short time. I'm speaking about less then 10 ms (our screen supports 144 Hz, that is a new image every 6.94 ms).
But all our approaches until now failed. We tried it with C#: WinForms were much too slow, WPF was faster, but we were still able to see the image, and even showing a texture with XNA framework did not work for us.
Do you have any suggestions for us? We're allowed to use C++ too, but we prefer using C#, so if your suggestions works with C# we would really much appreciate.
I would highly recommend using the XNA Framework for this. Some might consider it overkill but the fact is it is first of all designed to handle high throughput of frames and secondly has a relatively small learning curve.
I'm not a game developer but started by reading an article, modifying a simple project and creating one from scratch.
This would probably be your best bet in terms of the technologies you mentioned in your question.
UPDATE: Regarding measuring the actual time an image is shown, XNA would again be your closest guess short of dealing with specialized hardware and resorting to low-level programming.
My question is how programmers create, code, and organize subforms in general. By subforms, I mean those groups of controls that make up one UI experience. I'm looking for hints to help me better organize my form codes and to speed up the process of creating such forms. I swear to God, it takes way too long.
I've identified three broad groups of subform elements:
-Subforms have commands to do something.
-Subforms have data elements to carry out those commands.
-Subforms have states used to track things that aren't data.
The approach I use is to focus on what it takes to perform the commands which will determine which data elements are needed and how they should be validated.
Also, do programmers use check lists when creating forms?
p.s. I program as a hobby.
This is incredibly fuzzy. There is however a red flag though, you seem to be talking about UI as a starting point instead of the end result. That's a classic trap in winforms, the designer is rather good and makes it way too easy to endlessly tinker with form layouts. You forever keep adding and removing controls and event handlers as your ideas about how the program is supposed to work evolve.
This is backward and indeed a huge time sink. Effective design demands that you grab a piece of paper and focus on the structure of the program instead. The starting point is the model, the M in the MVC pattern. As you flesh out how the model should behave, it becomes obvious what kind of UI elements are necessary. And what commands should be available to the user.
The V emerges. Instead of jumping into the designer, sketch out what the view should look like. On paper. Make a rough draft of an organized way to present the data. And what operations are available to the user to alter them. Which selects the type of controls and the menus and buttons you'll need. Once that congeals, you can very quickly design the form and add the C. The event handlers that tie the UI to the model.
There's a very interesting tool available from Microsoft that helps you to avoid falling into this trap. I love the idea of it, it intentionally makes the UI design step imperfect. So you don't spend all that time pushing pixels around instead of focusing on the design of your program. It draws UI designs in a paper-and-pencil fashion, there are no straight lines. Incredibly effective not just for the programmer, also a "keep the customer focused and involved" fashion. So that the customer doesn't fall in the same trap either, nagging about a control being off by one pixel. It is called SketchFlow, link is here. It is otherwise the exact same analogue of paper and pencil, but with a 'runs on my machine' flourish.
Try CAB I'm not sure you should use it, but the pattern will help you understand how to write your gui layer in a good way.
I have developed an application that must be presented on exhibition as advertising. I want it to look more sexy! What tricks do you know that enhance the appearance of your applications?
What are the best design effects the developer can use for its application? I am speaking about: glowing, shadows, maybe forms of buttons, beautiful animation of splash screens and so on.
What is YOUR favourite effect?
If you have no feeling for what looks good, then don't try magic tricks like glowing shadows or sparky gradients, it will only look like some awkward app from the late 90s. Like Chris said, effects can ruin an application as quickly as it can make one.
There is no silver bullet for good design, the best tip for someone totally lost is: Less is more. Especially when it comes to colors, avoid using many different colors.
Look on other good looking apps (Photoshop CS4, Adobe Reader 9, OSX Preview, etc etc) they are actually really clean.
If you really want to use some wpf-powers an easy trick is opacity transitions, just keep all animations short (max 0.2 seconds). And for moving animations make sure to use acceleration and deceleration, otherwise the animation will look really weird.
In terms of enhancing your app, here are some things I personally like:
Dropshadow ... Creates the effect of depth on your application, ensure a global lighting direction otherwise, it is difficult to maintain a good general effect.
Scaling ... When transitioning from one state to another, the use of scaling draws attention to the control/screen
Easing ... Whenever there is movement in the screen, the movement should be eased from start to finish.
Shine ... For rollovers, I like a subtle shine to a control, this can be achieved by moving a subtle gradient across the control.
These are just a few effects ... I think it's import to note that effects can ruin an app as quickly as it can make one, so you want to make sure that the effects you use compliment your application.
From a UX perspective, my advice is that any interaction from the user should be exaggerated. For example, rollover effects, highlighting click interactions, etc.
So in conclusion:
Use effects to highlight user interaction
Ensure that effects are used in appropriate places
Keep the effects subtle
Avoid excessive use of effects
Hope that helps!
I found the following examples:
Vista Buttons:
Innerglows:
Glass Buttons:
The only one I really use for the moment is the Bitmap DropShadow and I do not use it that much just a little shadow. The example below is too much for me. I would reduce the ShadowDepth and the opacity.
(source: microsoft.com)
But the trick is too not use them too much and to use them with consistence. Do not change your effect style over and over all around your application. Otherwise, it will be hard to take it seriously.
I prefer my effects to be subtle. Some nice, quick, smooth fade in/fade out/glow effects can add a lot of style. If you're going to do bigger animation style effects, splined animations (rather than linear) usually look a little nicer.
Don't over-do it though. If you add too much, your application is going to become frustrating to the users that just want to get the task done.
Specific effects should be taylored to match the concept of the site. Care should be taken that effects do not get in the way of use, and do not have an overkill such that they have a significant impact on performance.
Try to give your visitors something, rather than hitting them with something.
Tasteful subtle effects can often be more dramatic than glaring bursts of over activity.
A site for an attorney for instance should be clear and more bland than one for say a games site which can get quite expressive and still be acceptable.
On color:
The correct mix of color will go a long way to improve appearance with minimal negative impact on use, just use care in different shades of a color group. Try not to have a tan wording on top of a different shade of light brown background for instance, it might degrade the ability to read the text.
I would try to stay away from a mix of colors from opposite sides of the color wheel or a mix of cool and warm colors on the same page.
Personally, I would reserve the neon colors for entertainment related things or where the time you expect visitors to stay is limited.
Often when you are trying to advertise a product or service, less is more.
I develop a utility that behaves like "Adobe photoshop". user can draw rectangle,circle,... with mouse pointer and then move or resize it. for this functionality, I assume each shape is a object that stored in a generic collection in a container object. when user wants to change anything I recognise that where he clicked and in behind of scence I select the target object and so on...
this way have a problem when objects in screen is lot or user loads a picture with high resolution.
What's your opinion?
How can I solve it?
This makes sense because the larger the data set, the more RAM and CPU will be required to handle it.
While performance issues are important to solve, a lot of it may be perceieved performance so something like a threading issue - where you have one thread trying to process the information and you block the UI thread which makes it look like the system is freezing.
There is a lot of information on StackOverflow that you may want to look at
C# Performance Optimization
C# Performance Best Practices
C# Performance Multi threading
C# Performance Collections (Since you said you were using a collection)
Use a profiler such as dotTrace and find out which method is the one most called and the one that takes the most amount of time to process. Those are the ones you want to try to optimize. Other than that, you may have to go down to the GPU to try to speed things up.
About these kind of problem, think about parallel extensions :
http://msdn.microsoft.com/en-us/concurrency/default.aspx
The more cpu you have, the faster your program is running.
The thing is that in hi resolution the computer needs to use more the processor, then this occurs, remember that this also occurs in The Gimp, even in Adobe Photoshop.
Regards.
Look into using a performance analyzing tool (such as ANTS Profiler) to help you pinpoint exactly where the bottle necks are occurring. True graphical computations on a high res photo require alot of resources, but I would assume the logic you are using to manage and find your objects require some tuning up as well.
I high-resolution image takes up a lot of memory (more bits-per-pixel). As such, any operation that you do to it means more bits to manipulate.
Does your program utilise "layers"?
If not, then I'm guessing you are adding components directly to the image - which means each operation has to manipulate the bits. So if you aren't using layers, then you should definitely start. Layers will allow you to draw operations to the screen but only merge them into the base high-resolution image once - when you save!
What library from Windows are you using to open the image?
If you are using System.Drawing then you are actually using GDI+ as it is a wrapper on top of it. GDI+ is nice for a lot of things because it simplies tons of operations, however it isn't the fastest in the world. For example using the [Get|Set]Pixel methods are MUCH slower than working directly on the BitmapData. As there are tons of articles on speeding up operations on top of GDI+ I will not re-iterate them here.
I hope the information I've provided answer some of your questions causes new ones. Good luck!