Develop Reference

EmguCV: Emplace one Mat onto another?

In C++ if you wanted to emplace one mat into another, the code would simply be:
clone_img.emplace(out_mat);
Now, I know in C# there is no real equivalent to the "emplace" method. If I was working with other data types in a more standard collection, I can find the answer for what I want to do on Google. Working with a cv::Mat is a bit different though, and I can't find anything about that.
There is a Mat.PushBack method, but it doesn't construct the new object in-place within the collection. Or does that not matter?
What is the C#/EmguCV equivalent of this emplacement, and what would be the differences under the hood to be aware of?

I found the answer for what I wanted to do, although it may not exactly answer this above question.
What I wanted to do was to create an empty Mat, and then call Mat.emplace() to put something else in it.
I found out it was as simple as doing:
Mat newMat = old_mat;

How do I draw things differently depending on the case in XNA?

I have a StatBarView class that holds a Stat, an int named percentage and two Colors. In the Update() method I smoothly change around the percentage value of the bar, how full it has to be. Next up I have four Draw() methods, one for drawing the bar small, one for medium, one for large, and one for drawing it as text instead of graphically.
It works, but.. I feel like this will become a mess if I want to implement more drawing cases.
I could turn the 'text view' into it's own StatTextView, but that only moves the problem elsewhere. I also want to avoid having to pass along all kinds of parameters to the draw method, it would make me run all over the place if I want to change the sizes of a few things. I'd also like to avoid some massive method using switch statements, that feels even worse.
I considered passing along an IStatBarContext that has a Draw(int percentage), which would work, but feels very complicated.
Would I have to call Stat.Draw(spriteBatch, position, new StatBarLarge()) on every iteration of Draw()? That's a load of useless new objects per second. Besides, new StatBarString() would make no use of that percentage stat. I think I went wrong with my design somewhere.
That said, I don't know how to actually -do- make this code cleaner. Would someone help me out?

It sounds like your last example/choice is spot on. It even has a name, the Strategy pattern.
In the class based version of this pattern, you would normally just pass in a new object every time (as in your example) but because this is in the Draw method, I would just have a sample of each strategy stored in your class and pass the existing reference.
Another way to implement this pattern is by using delegates. To do so you would have the Draw method take a delegate with the information you need. Something like:
public void Draw(SpriteBatch spriteBatch, Vector3 position, Action<int> drawStrategy)
{
...
drawStrategy(percentage);
}
You would then pass the function for large, small, text, etc. to this function. Action<int> was just an example of course, you can have it return values or take additional parameters as needed.
If the text-version doesn't use percentage, that is a code-smell, but you may not need to worry about it to much. Strategy is definitely the way to go here.

Which kind of method signature do you prefer and why?

Ok, this is probably highly subjective but here it comes:
Let's assume I'm writing a method that will take a printscreen of some region of the screen. Which method signature would you prefer and why?
Bitmap DoPrintScreen(int x, int y, int width, int height);
Bitmap DoPrintScreen(Rectangle rect);
Bitmap DoPrintScreen(Point point, Size size);
Other
Why?
I keep seeing myself repeatedly implementing both 1) and 2) (redirecting one of them to the other) but I end up usually just using one of them, so there really is no point in having both. I can't decide which would be better. Maybe I should use the signature that looks the most with the method I'll be calling to make the printscreen?

It depends. If this is a library for general use, by all means add all three. The .NET framework, especially GDI+, is full of examples of this. If the conversion is trivial, it's not much effort, and your users will be thankful.
If it's just an internal class, I'd go for the option that is easiest to use from the call site. For example, if the caller already has a Rectangle available, the Rectangle overload is better. If there are multiple call sites with different preferences, it's probably better to add multiple overloads as well.

Rectangle best describes the behavior of the function (at least I hope it does!) The X & Y associate with width & height so as to define a rectangle; they are not arbitrary unrelated variables.

I would go with 2)
Bitmap DoPrintScreen(Rectangle rect);
As mark said the parameters can be swapped in the following:
Bitmap DoPrintScreen(int x, int y, int width, int height);
I wouldn't choose this as it is not as explicit as 2) to someone else reading it. Whereas there is no ambiguity to someone read 2)
Bitmap DoPrintScreen(Point point, Size size);
Of course that's just my opinion of course!!!

If you only end up calling one of these overloads, then there's really no point in having the other two sitting around. There's nothing I hate more than having to sift through 27 overloads of some method, hoping that a) I find the right one for my purposes, and b) the person who wrote this mess actually ran and tested the overload I'm using even once.
In the specific case of a screen-capture method, the overload with the Rectangle parameter would probably be the most handy, since forms always have a rectangle associated with them. Also, if you need to grab the same screen area repeatedly, it's easier to save one variable (a Rectangle) than four (x, y, width and height).

The best one is
Bitmap DoPrintScreen(Rectangle screenArea);
If you think about the method parameters as being part of a "concept", in this case the concept of a screen area, then the other options don't abstract that concept nicely enough.
Also, use a good name for the parameter, because it might make calling code even more clear by the use of named parameters in C# 4.0.

I would personally include the three of them, letting the user choose which one she/he prefers to use, all to offer the most freedom of use possible to the user. No one likes to be handcuffed. Well, not in programming! ;)

Rectangle is probably the most clear because the argument does not depend on the position. It would be easy for a user to accidentally swap x and y or width and height.
Point/Size is also better than x-y-width-height, and sometimes the extra explicitness can be a little more clear to read.
But ultimately, there's no good reason to not use all three overloads.

I think you should select the version that maps best to the other methods that would be used in conjunction with your code. I am referring to .Net methods and methods from other standard or common 3-rd party libraries. In that way the code looks uniform and the same objects can be passed to other methods directly.

I would provide all 3 if it would be convenient for the consumer. After all, your actual implementation will (or should) only exist in one place. All of the other overloaded methods will simply extract the appropriate parameters and pass them to the local method with the actual code.
...so it's a convenience for your users with little to no effort on your part. Win/Win.

Both - 1 and 2.
And also one without params for full-screen =)
Some times you have separated x,y,width, height,
some times you already have rectangle.
Varian 3 - IMHO is very rare =)
But user always can convert values to rectangle, or break apart rectangle to values)
I think this is philosophical question.
So make them all or pick random one )))

All 3. Like you said, you're going to redirect them to 2 any who so, why not keep all three? I do think you should change the Rectangle parameter name to something more meaningful - like printArea.
cheers.

What's the fastest way to return a list of objects in C#?

I'm writing a plug-in for a 3D modeling program. There is a a feature of the API where you can intercept the display pipeline and insert additional geometry that will be displayed with out actually being in the model (you can see it but you can't select/move/delete etc. etc..).
Part of this feature of the API is a method that gets called on every screen refresh that is used to tell the program what extra geometry to display. Right now I have a HashSet that is iterated through with a foreach statement. OnBrep is the generic geometry class of the API.
I have an additional command that will dump the "Ghost" geometry into the actual model. I've found, that if the geometry is actually in the model the display speeds up a lot. So I'm wondering if there is a faster way to provided the list of objects to the program? Would a simple one dimensional array be significantly faster than a HashSet<>?

The fastest way to return a collection of objects is to return either (a) the actual physical type that was used internally to build up the collection, or (b) a type that can be cast to in such a way that data is not copied in memory. As soon as you start copying data (e.g. CopyTo, ToArray, ToList, a copy constructor, etc) you have lost time.
Having said that, unless the number of items is large, this will be a micro-optimisation and therefore probably not worth doing. In that case, just return the collection type that would be of most use to the calling code. If you are unusure, do some timing tests rather than taking a guess.

This here is an extensive study on the performance of hashset/dictionary/generic list
But it's about key lookups
Personnaly I think that a normal or generic list is faster for a foreach operation since it involves no indexed items/overhead (esp inserting etc should be faster).... But this is just a gut feeling.

Usually when working with 3D graphics, you get the best performance if you manage to reduce the draw calls/state changes as much as possible.
In your case I'd try to reduce the draw calls to a minimum by merging your adorned geometry or trying to use some sort of batching feature if it's available.
It's very likely that the frame drop is not because of using a hash list/dictionary instead of an array. (Unless there's a broken/expensive hashing function somewhere...).

What is the best way to convert between a Media.Matrix to a Drawing2D.Matrix

I have the need to convert from the WPF Media.Matrix to the Windows Forms Drawing2D.Matrix and so I did the following:
public static System.Drawing.Drawing2D.Matrix ConvertToDrawing2DMatrix( Matrix matrix)
{
return new System.Drawing.Drawing2D.Matrix((float)matrix.M11,
(float)matrix.M12,
(float)matrix.M21,
(float)matrix.M22,
(float)matrix.OffsetX,
(float)matrix.OffsetY);
}
and was wondering if this was the best approach.

If your code works fine then I would say that probably is the best method in your case. I looked all over google trying to find a way to do this and other than a 3rd party library I couldn't seem to find a way.

As others have said that is probably the best way. I just wanted to add that depending on the .NET version and your coding policy you could consider adding "this" to the method signature and make it an extension method for easier access, like this:
using Drawing2DMatrix = System.Drawing.Drawing2D.Matrix;
public static Drawing2DMatrix ConvertToDrawing2DMatrix(this Matrix matrix) {...}
Then you could call it like this:
Drawing2DMatrix newMatrix = myMediaMatrixInstance.ConvertToDrawing2DMatrix();
Just a suggestion.

I'd say that's the best way. The System.Drawing matrix is stored in unmanaged memory and the WPF matrix is a struct on the managed stack, so any trickery in doing a block copy would require some unsafe code for very little, if any, perf improvement.