i've become rather familiar system.drawing namespace in terms of knowing basic steps of how generate image, draw on it, write text on it, etc. however, it's darn slow approaching print-quality. have seen suggestions using com talk native windows gdi quicker wondering if there optimizations make allow high speed, high quality image generation. have tried playing anti-aliasing options , such available graphics, bitmap , image objects there other techniques can employ high speed?
writing had thought use task library in .net 4 more work though each generation task wouldn't quicker.
anyway, thoughts , comments appreciated.
thanks!
if want raw speed, best option use directx. next best use gdi c++ , provide managed interface call it. p/invoke gdi directly c#, , last use gdi+ in c#. depending on you're doing may not see huge difference. multithreading may not if you're limited speed @ graphics card can driven gdi+, beneficial if you're processor bound while working out "what draw". if you're printing many images in sequence, may gain running precalculation, rendering, , printing "phases" on separate threads.
however, there number of things can optimise redraw speed, both optimisations , compromises, , these approaches apply rendering system choose. indeed, of these stem same principles used when optimising code.
how can minimise amount draw?
firstly, eliminate unnecessary work. think each element drawing - necessary? simpler design can better while saving lot of rendering effort. consider whether grad fill can replaced flat fill, or whether rounded rectangle acceptable plain rectangle (and test whether doing provides speed benefit on hardware before throwing away!)
challenge assumptions - e.g. "high resolution" requirement - if you're printing on dye-sub printer (which process introduces bit of colour bleed) or cmyk printer uses form of dithering mix colours (which has lower practical resolution dot pitch printer can resolve), relatively low resolution anti-aliased image can produce result super-high-res one. if you're outputting 2400dpi black , white printer, may still find 1200dpi or 600dpi acceptable (you ever decreasing returns increase resolution, , people won't notice difference between 600dpi , 2400dpi). print typical examples out using different source resolutions see results like. if can halve resolution potentially render as 4x faster.
generally try avoid overdrawing same area - if want draw black frame around region, draw white rectangle inside black rectangle, means filling pixels in middle twice. may improve performance drawing 4 black rectangles around outside draw frame exactly. conversely, if have lot of drawing primitives, can reduce number of primitives you're drawing? e.g. if drawing lot of stripes, can draw alternating rectangles of different colours (= 2n rectangles), or can fill entire background 1 colour , draw rectangles second colour (= n+1 rectangles). reducing number of individual calls gdi+ methods can provide significant gains, if have fast graphics hardware.
if draw portion of image more once, consider caching (render bitmap , blitting final image when needed). more complex sub-image is, more caching pay off. example, if have repeating pattern ruler, don't draw every ruler marking separate line - render repeating section of ruler (e.g. 10 lines or 50) , blit prerendered few times draw final ruler.
similarly, avoid doing lots of unnecessary work (like many measurestring calls values precalculated once or approximated. or if you're stepping through lot of y values, try adding offset on each iteration rather recaclualting absolute position using mutliples every time).
try "batch" drawing minimise number of state changes and/or drawing method calls necessary - e.g. draw elements in 1 colour/texture/brush before move on next colour. use "batch" rendering calls (e.g. draw polyline primitive once rather calling drawline 100 times).
if you're doing per-pixel operations, it's lot faster grab raw image buffer , manipulate directly call getpixel/setpixel methods.
and you've mentioned, can turn off expensive operations such anti-aliasing , font smoothing won't of any/much benefit in specific case.
and of course, @ code you're rendering - profile , apply usual optimisations flow efficiently.
lastly, there comes point should consider whether hardware upgrade might cheap , effective solution - if have slow pc , low end graphics card there may significant gain had buying new pc better graphics card in it. or if images huge, may find couple of gb more ram eliminates virtual memory paging overheads. may sound expensive, there comes point cost/benefit of new hardware better ploughing more money additional work on optimisations (and ever decreasing returns).
Comments
Post a Comment