Initial tests indicate that GDI+ (writing in VB.NET) is not fast enough for my purposes. My application needs to be able to draw tens of thousands of particles (coloured circles, very preferably anti-aliased) in a full screen resolution at 20+ frames per second.
I'm hesitant to step away from GDI+ since I also require many of the other advanced drawing features (dash patterns, images, text, paths, fills) of GDI+.
Looking for good advice about using OpenGL, DirectX or other platforms to speed up particle rendering from within VB.NET. My app is strictly 2D.
Goodwill,
David
If you want to use VB.NET, then you can go with XNA or SlimDX.
I have some experience in creating games with GDI+ and XNA, and I can understand that GDI+ is giving you trouble.
If I where you I'd check out XNA, it's much faster than GDI+ because it actually uses your video card for drawing and it has a lot of good documentation and examples online.
SlimDX also looks good but I don't have any experience with it. SlimDX is basically the DirectX API for .NET.
The only way to get the speed you need is to move away from software rendering to hardware rendering... and unfortunately that does mean moving to OpenGL or DirectX.
The alternative is to try and optimise your graphics routines to only draw the particles that need to be drawn, not the whole screen/window.
I would agree with JaredPar that you're better off profiling first to determine if your existing codebase can be improved before making a huge switch to a new framework. DirectX is not the easiest framework if you're unfamiliar with it.
The most significant speed increase I found, when writing a game maker with GDI+, was to convert my bitmaps to Format32bppPArgb;-
SuperFastBitmap = ConvertImagePixelFormat(SlowBitmap, Imaging.PixelFormat.Format32bppPArgb)
If they are not in this format already, you'll see the difference immediately when you convert.
It's possible the problem is in your algorithm and not GDI+. Profiling is the only way to know for sure. Without a profile it's very possible you will switch to a new GUI framework and hit the exact same problems.
If you did profile, what part of GDI+ was causing a problem?
As Jared said,
it could be that a significant fraction of your cycles are not going into GDI, and you might be able to reduce those.
A simple way to find those is to halt it at random a few times and examine the stack. The chance that you will catch it in the act of wasting time is equal to the fraction of time being wasted.
Any instruction or call instruction that appears on more than one such sample is something that, if you could replace it, you would see a speedup.
In general, the method is this.
As you're working in VB.net, have you tried using WPF (Part of .net since 3.0)? As WPF is based on DirectX rather than GDI+, that should give you the speed you need, although developing WPF is not straight-forward at all.
Because the GDI+ is not moved by the graphics card, it's slow to render because it uses the CPU to render. At least, you can use DirectX or SlimDX.
(sorry for bad english)
See This: http://msdn.microsoft.com/en-us/library/windows/desktop/ff729480%28v=vs.85%29.aspx
http://www.codeproject.com/Articles/159586/Starting-DirectX-with-Visual-Basic-NET
Related
I have a Windows application that currently renders graphics largely using MFC that I'd like to change to get better use out of the GPU. Most of the graphics are straightforward and could easily be built up into a scene graph, but some of the graphics could prove very difficult. Specifically, in addition to the normal mesh type objects, I'm also dealing with point clouds which are liable to contain billions of Cartesian stored in a very compact manner that use quite a lot of custom culling techniques to be displayed in real time (Example). What I'm looking for is a mechanism that does the bulk of the scene rendering to a buffer and then gives me access to that buffer, a z buffer, and camera parameters such that I can modify them before putting them out to the display. I'm wondering whether this is possible with Direct3D, OpenGL or possibly use a higher level framework like OpenSceneGraph, and what would be the best starting point? Given the software is Windows based, I'd probably prefer to use Direct3D as this is likely to lead to fewest driver issues which I'm eager to avoid. OpenSceneGraph seems to provide custom culling via octrees, which are close but not identical to what I'm using.
Edit: To clarify a bit more, currently I have the following;
A display list / scene in memory which will typically contain up to a few million triangles, lines, and pieces of text, which I cull in software and output to a bitmap using low performing drawing primitives
A point cloud in memory which may contain billions of points in a highly compressed format (~4.5 bytes per 3d point) which I cull and output to the same bitmap
Cursor information that gets added to the bitmap prior to output
A camera, z-buffer and attribute buffers for navigation and picking purposes
The slow bit is the highlighted part of section 1 which I'd like to replace with GPU rendering of some kind. The solution I envisage is to build a scene for the GPU, render it to a bitmap (with matching z-buffer) based on my current camera parameters and then add my point cloud prior to output.
Alternatively, I could move to a scene based framework that managed the cameras and navigation for me and provide points in view as spheres or splats based on volume and level of detail during the rendering loop. In this scenario I'd also need to be able add cursor information to the view.
In either scenario, the hosting application will be MFC C++ based on VS2017 which would require too much work to change for the purposes of this exercise.
It's hard to say exactly based on your description of a complex problem.
OSG can probably do what you're looking for.
Depending on your timeframe, I'd consider eschewing both OpenGL (OSG) and DirectX in favor of the newer Vulkan 3D API. It's a successor to both D3D and OGL, and is designed by the GPU manufacturers themselves to provide optimal performance exceeding both of its predecessors.
The OSG project is currently developing a Vulkan scenegraph known as VSG, which already demonstrates superior performance to OSG and will have more generalized culling ability.
I've worked a bunch with point clouds and am pretty experienced with them, but I'm not exactly clear on what you're proposing to do.
If you want to actually have a verbal discussion about the matter, I'm pretty easy to find (my company is AlphaPixel -- AlphaPixel.com) and you could call us. I'm in the European time zone right now, it's not clear from your question where you are but you sound US-based.
Doing software development, you also want to verify the robustness of your code. Especially in image processing - I'm pretty sure that this applies to other fields, too, like bio sciences simulators - your input data can vary a lot.
So far, I've faced the situation that a rolled-out piece of software crashes and causes some irritation at the customer’s site. The framework holding the image processing algorithms is pretty stable, crashes usually occur in the algorithms itself.
Image you use a 3rd-party closed source image processing library. To figure out any problematic code you go manually through the code you wrote. Everything around the blackboxed function seems pretty robust.
Unfortunately, as soon as an image with this very special gradient on this very particular region, the blackboxed function crashes.
Enveloping all 3rd-party functions with try-catches is not taking out all risks. Especially on embedded devices you may just get a segfault.
To avoid unhappy customers und therefore eradicate possible crashes, I started to do white-noise-tests using random-generated patterns as input images and let this tests run for a few days - which actually gave my some confidence (and in some cases, more mistrust) in the robustness on an closed-source function.
Compared to an analytical (or using integration / unit tests) approach is seems like ... steamroller tactics. It is just not very elegant.
Coming to my question: Is this empirical testing approach appropriate? Are there better solutions available?
In blender game engine, what are the advantages to using the add object actuator compared to using scene.addObject?
I know there is something about threading?
i can't give you an answer for the threading question.
But if you want to know more:
Usually it can be a (little) performance difference.
But it is casedependent. If you want to spawn an item by pressing a key it is better to do it with bricks, because they are faster in most cases.
But i would never go for a minimal performancewin and a big sacrifice in the workflow. scene.addObject in a pythoncontroller gives much more flexibility. You can keep the reference and add different behavior right after spawning.
Imagine you have a shattered Window and are spawning broken Tiles instead of the original window plane. If you just spawn them it is boring. You should give each tile a starting speed and rotation. With scene.addObject you can achieve that! With an actuator you would have to programm individual logicsetups in a state for a starting behavior. Tons of work, more than a little bit performance you may win. My Performancetest did not show a big difference though.
Good luck! i hope you find the answer.
I want to make an extremely large bitmap (250,000 pixels on each side, to be eventually written out as BigTIFF). I don't see a memory size or dimensional limit anywhere in the docs, can Core Graphics handle it?
CG is not designed for that kind of workload.
(I'd be surprised if you found any general-purpose graphics framework that is, frankly. If you're pushing images that big, you're going to have to write your own code to get anything done in a reasonable amount of time.)
In my experience, images started to fail once dimensions got over 32767 or so. Not in any organized way, just crashes and hard-to-repro failures; certain parts of the API would work, others wouldn't. Things may be better in 64-bit but I wouldn't count on it.
I am developing a cocoa application (Mac) and wanted to know what are your tips, best practices, ... for an efficient Cocoa application, which starts in less than 1 second and which is very responsive.
I've installed twitter for Mac and was amazed by its speed. Is it using special tricks?
Thanks in advance for your ideas :)
Three things that can help reduce startup time and improve overall performance are:
Defer loading resources until they're actually needed.
Profile your app to identify the parts that have the highest cost (whether you measure that in execution time, memory, or something else). Then work to reduce the cost of those operations or figure out a way to do them less or at a different time.
Take advantage of the hardware. Most machines these days have at least two processing cores and advanced graphics processors; use GCD, Quartz, Core Animation, and other technologies to take advantage of the available power.
I don't think there are really any "tricks" per se. You just profile your code with Instruments, and eliminate the slow areas. It's the same as optimising any code; don't block the main thread with disk reads/writes, use lazy loading where appropriate, etc.
A lot of it may be simply tightly written, good quality code. These sort of apps don't tend to rely on clunky frameworks etc.
Do only what you need to do and only when you need to do it.