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.
Related
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.
imageresing.net community and developers.
Please, clarify me some details about imageresing.net internals.
Does imageresing.net use .NET Drawing library to recompress jpegs? If not - does it use a 3rd party engine or some internal algorithms?
Are there performance benchmarks? I'd like to compare imageresing.net with other libraries: libjpeg, Intel Integrated Performance Primitives, etc.
Thanks in advance,
Anton
ImageResizer offers 3 imaging pipelines.
GDI+ (System.Drawing) The default. 2-pass high-quality bicubic with pre-smoothing. Very fast for the quality provided. (Avg. 200-300ms for resizing.) A recent windows update makes GDI+ parallelize poorly, but this is being actively investigated by MSFT.
WIC (What WPF also uses). 4-8x faster (20-200ms for resizing). Single-pass resizing causes lots of moire artifacts and causes blurriness (in both Fant and Bicubic modes). No really high quality resizing is available within Windows Imaging Components.
FreeImage. If you need to support DSLR formats or access Lanczos resampling (top-tier quality), FreeImage is your library. It's slower than the others (often 800-2400ms), large, monolithic, and hard to audit, so we only recommend using it with trusted image data. We use a custom version of FreeImage built against libjpeg-turbo, which is significantly faster than libjpeg.
You can mix and match encoders, decoders, and (to some extent) resizing algorithms. Some algorithms are implemented internally for quality reasons, while most are implemented in C/C++ in dependencies.
End-to-end comparison benchmarking is kind of absurd if you care about photo quality, since you can never compare apples to apples. Back in 2011, I did some benchmarks between GDI+ and WIC, but photographers and graphics designers tend to find WIC image quality unacceptable, so it's not particularly fair.
We regularly benchmark each pipeline against itself to detect performance improvements or regressions, but comparing pipelines can be deceptive for a numer of reasons:
Do you care about metadata? libjpeg-turbo is (wierdly) 2-3x faster at reading jpegs when you disable metadata parsing. If you want to auto-rotate based on camera exif data, you'll need that info.
Do you care about color correctness? Jpeg isn't an RGB format. If it has an ICC profile, the right thing to do is convert to sRGB before you resize. That's slow.
Do you care about resizing quality? There are a hundred ways to implement a bicubic resizing filter. Some fast, some slow, most ugly, some accurate. Bicubic WIC != Bicubic GDI+. You can get < 20ms end-to-end out of ImageResizer WIC in nearest neighbor mode - if you're cool with the visual results.
Do you care about output file size? If you're willing to spend more clock cycles, you can gain 30-80% reductions in PNG/GIF file sizes, and 5-15% in jpeg. If you want to add 150-600ms per request, ImageResizer can create WebP images that halve your bandwidth costs (WebP is more costly to encode than jpeg).
You can make sense of micro-benchmarks (is libjpeg-turbo 40% faster than libjpeg under the same circumstances, etc). You can even compare certain simple low-quality image resizing filters (nearest-neighbor, box, bilinear) after excluding encoding, decoding, and color transformation.
The problem is that truly high-quality resizing is really complex, and never implemented the same way twice. There are a vanishingly small number of high-quality implementations, and an even tinier number that have sub-second performance. I ordered a dozen textbooks on image processing to see if I could find a reference implementation, but the topic is... expertly avoided by most, and only briefly touched on by others. Edge-pixel handling, pre-filtering, and performance optimization are never mentioned.
I've funded a lot of research into fast high-quality image resizing, but we haven't been able to match GDI+ yet. ImageResizer's default configuration tends to beat Photoshop quality on many types of images.
A fourth pipeline may be added to ImageResizer in the near future, based on our fork of libgd with custom resizing algorithms. No promises yet, but we may have something nearly as high quality as GDI+ with similar single-threaded (but better concurrent) performance.
All our source code is on GitHub, so if you find something fast that you'd like to demo as a plugin or alternate pipeline, we'd love to hear about it.
I've become rather familiar with the System.Drawing namespace in terms of knowing the basic steps of how to generate an image, draw on it, write text on it, etc. However, it's so darn slow for anything approaching print-quality. I have seen some suggestions using COM to talk to native Windows GDI to do this quicker but I was wondering if there were any optimizations I could make to allow for high speed, high quality image generation. I have tried playing with the anti-aliasing options and such immediately available to the Graphics, Bitmap and Image objects but are there any other techniques I can employ to do this high speed?
Writing this I just had the thought to use the task library in .Net 4 to do MORE work even though each generation task wouldn't be any quicker.
Anyway, thoughts and comments appreciated.
Thanks!
If you want raw speed, the best option is to use DirectX. The next best is probably to use GDI from C++ and provide a managed interface to call it. Then probably to p/invoke to GDI directly from C#, and last to use GDI+ in C#. But depending on what you're doing you may not see a huge difference. Multithreading may not help you if you're limited by the speed at which the graphics card can be driven by GDI+, but could be beneficial if you're processor bound while working out "what to draw". If you're printing many images in sequence, you may gain by running precalculation, rendering, and printing "phases" on separate threads.
However, there are a number of things you can do to optimise redraw speed, both optimisations and compromises, and these approaches will apply to any rendering system you choose. Indeed, most of these stem from the same principles used when optimising code.
How can you minimise the amount that you draw?
Firstly, eliminate unnecessary work. Think about each element you are drawing - is it really necessary? Often a simpler design can actually look better while saving a lot of rendering effort. Consider whether a grad fill can be replaced by a flat fill, or whether a rounded rectangle will look acceptable as a plain rectangle (and test whether doing this even provides any speed benefit on your hardware before throwing it away!)
Challenge your assumptions - e.g. the "high resolution" requirement - often if you're printing on something like a dye-sub printer (which is a process that introduces a bit of colour bleed) or a CMYK printer that uses any form of dithering to mix colours (which has a much lower practical resolution than the dot pitch the printer can resolve), a relatively low resolution anti-aliased image can often produce just as good a result as a super-high-res one. If you're outputting to a 2400dpi black and white printer, you may still find that 1200dpi or even 600dpi is acceptable (you get ever decreasing returns as you increase the resolution, and most people won't notice the difference between 600dpi and 2400dpi). Just print some typical examples out using different source resolutions to see what the results are like. If you can halve the resolution you could potentially render as much as 4x faster.
Generally try to avoid overdrawing the same area - If you want to draw a black frame around a region, you could draw a white rectangle inside a black rectangle, but this means filling all the pixels in the middle twice. You may improve the performance by drawing 4 black rectangles around the outside to draw the frame exactly. Conversely, if you have a lot of drawing primitives, can you reduce the number of primitives you're drawing? e.g. If you are drawing a lot of stripes, you can draw alternating rectangles of different colours (= 2n rectangles), or you can fill the entire background with one colour and then only draw the rectangles for the second colour (= n+1 rectangles). Reducing the number of individual calls to GDI+ methods can often provide significant gains, especially if you have fast graphics hardware.
If you draw any portion of the image more than once, consider caching it (render it into a bitmap and then blitting it to your final image when needed). The more complex this sub-image is, the more likely it is that caching it will pay off. For example, if you have a repeating pattern like a ruler, don't draw every ruler marking as a separate line - render a repeating section of the ruler (e.g. 10 lines or 50) and then blit this prerendered only a few times to draw the final ruler.
Similarly, avoid doing lots of unnecessary work (like many MeasureString calls for values that could be precalculated once or even approximated. Or if you're stepping through a lot of Y values, try to do it by adding an offset on each iteration rather than recaclualting the absolute position using mutliples every time).
Try to "batch" drawing to minimise the number of state changes and/or drawing method calls that are necessary - e.g. draw all the elements that are in one colour/texture/brush before you move on to the next colour. Use "batch" rendering calls (e.g. Draw a polyline primitive once rather than calling DrawLine 100 times).
If you're doing any per-pixel operations, then it's usually a lot faster to grab the raw image buffer and manipulate it directly than to call GetPixel/SetPixel methods.
And as you've already mentioned, you can turn off expensive operations such as anti-aliasing and font smoothing that won't be of any/much benefit in your specific case.
And of course, look at the code you're rendering with - profile it and apply the usual optimisations to help it flow efficiently.
Lastly, there comes a point where you should consider whether a hardware upgrade might be a cheap and effective solution - if you have a slow PC and a low end graphics card there may be a significant gain to be had by just buying a new PC with a better graphics card in it. Or if the images are huge, you may find a couple of GB more RAM eliminates virtual memory paging overheads. It may sound expensive, but there comes a point where the cost/benefit of new hardware is better than ploughing more money into additional work on optimisations (and their ever decreasing returns).
I have a few ideas:
Look at the code in Paint.net. It is an open source paint program written in C#. It could give you some good ideas. You could certainly do this in conjunction with ideas 2 and 3.
If the jobs need to be done in an "immediate" way, you could use something asynchronous to create the images. Depending on the scope of the overall application, you might even use something like NServiceBus to queue an image processing component with the task. Once the task is completed, the sending component would receive a notification via subscribing to the message published upon completion.
The task based solution is good for delayed processing. You could batch the creation of the images and use either the Task approach or something called Quartz.net (http://quartznet.sourceforge.net). It's an open source job scheduler that I use for all my time based jobs.
You can create a new Bitmap image and do LockBits(...), specifying the pixel format you want. Once you have the bits, if you want to use unmanaged code to draw into it, bring in the library, pin the data in memory, and use that library against it. I think you can use GDI+ against raw pixel data, but I was under the impression that System.Drawing is already a thin layer on top of GDI+. Anyways, whether or not I'm wrong about that, with LockBits, you have direct access to pixel data, which can be as fast or slow as you program it.
Once you're done with drawing, you can UnlockBits and viola you have the new image.
I have a question about the Bitmap class. If you want to set a lot of pixels on the bitmap, then you can use the SetPixel method, but it's very slow. There is a lot of documentation on how you can speed it up with the LockBits methodes etc, so i've created a method: SetFastPixelto speed it up a bit.
However, and I'm really confused by it: Why doesn't microsoft change the implementation of SetPixel() to an implementation that's faster? In other words, is there and advantage for using SetPixel instead of the LockBits method?
Cases where SetFastPixel probably doesn't work:
Monochrome devices (eight pixels packed into one byte)
Planar devices (16-color VGA cards have a strange memory layout and require hardware assistance)
Indexed palette devices (SetPixel handles the RGB to palette index mapping)
Printers (I've no idea how this would work via LockBits)
Multi-monitor configurations where each card has a different pixel format
SetPixel is designed to handle all of the above, at the expense of being slow. If you're willing to sacrifice some of the above points, or if you're happy to handle them in your application, then you have the ability to draw images via LockBits.
To make an implementation that handles a specific bitmap format is easy, but there are a lot of different ways that an image can be stored in memory, so implementing a solution that handles all formats is a lot more complex.
A bitmap can for example be stored right side up or upside down in memory, with or without padding between lines, with many different number of bits per pixel.
Implementing that is just more work that it's worth to make the method a bit faster. Setting a single pixel at a time is inherently slow, so you shouldn't use that method anyway if you want speed.
Calling a method to set a single pixel is inherently slow, no matter how you implement it, because, for each call, you must compute and check indexes, convert pixel format, etc.
Direct3D was created just for this purpose. Despite its name, it's still possible to do raw 2D pixel manipulation. Generally put, you do it as:
Create Direct3D context and device
Create an offscreen surface
Lock offscreen surface, render to its display buffer, unlock
Copy offscreen buffer to device.
Yes, it is a lot more complicated than GDI, but it's coupled tightly to the hardware and drivers so that you control exactly where the rendering is occurring and how it's being displayed to the screen. You'll never want to do any high performing graphics with GDI again.
They do not care because most people dont use it like that. C# is normally not used to render videos - and if you need stuff like that there are faster alternatives.
The classes in System.Drawing are just a thin layer over the C++ classes used in GDI+. Microsoft was not going expose a common interface (System.Drawing & GDI+) and have two classes which are supposed to act the same perform differently.
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!