What faster ? Creating rectangle texture by SpriteBatch, or load rectangle texture and scaling ?
Could you please rephrase your question? Spritebatch doesn´t create texture, Texture2D.SetData does. Well, in fact, not sure what you mean by second part of your question either.
Of course i will.
I create a topic, because cra0zy ask me for that.
Original message is:
Guys, who can help me to understand, creating texture in runtime is harder, than loadind textures and scalings ?
So, i create a rendertarget2D, draw on it, and store that object.
i will show you result.
Here an example.
All bars on this image stored in Rendertarget2D and on Draw() method i just merging all rendertagets to one texture and draw it on framebuffer.
But, time from time i got images part blinking (dissapear on 1-2 frames and draw then again). So, i look to GPU load, and define, that no activity rendering take about 25% of my GPU time. So i want to find more performance way for my application, because i’m time from time use 3-5 windows with my charts.
Here is anothe r screenshot, where i use another Drawing Areas, for displaying another types of graphic. This Areas each stored in separate RenderTarget2D and merging in proper order before Displaying on framebuffer too.
That’s what you meant… You fraze it a bit weird at start.
What I do about rectangle texture is create a 1x1 pixel texture with white color, and then just stretch/color it during draw.
Sounds like you are doing something very shady if you have the problem with stuff disappearing, post some code about what you are doing.
Ohh, let’s very complicated question, so, i will write it now, but it takes a long time. So i begin…
Preamble:
I want to reach a goal in writing dynamically charts-engine, what using Direct3D (now i wanna openGL, but can’t use it, because i can’t host is as control in WPF), and drawing 60fps without lagging for best usability.
So we with my “partner” begin to use monogame, coz he have a third party hosting on WPF (WPF is a one of demanding rules).
Monogame was quite pretty engine, before we got a huge count drawing objects on a screen.
First version of charting engine was with using just a backbuffer with calculations all-objects-in-every-frame. That was a bad idea, because this method didn’t reach many of common targets (as drawing objects on a chart for example), and when we create few instances of control, CPU was loaded and we begin to loss FPS.
So this method was refused by us.
Preamble TWO (few more details):
How the system works.
We got some data, from some sourse (isn’t matter for now). Then we must display some databars. Here you can see an example of web version.
Next idea was: create layer-based solution. I know,guys, that is a tonns of charting engines but, no one charting engine can’t handle huge counts of objects be so responsive, when getting a 20-80 ntw values each second. Now we handle changes of 60 new data values and this limitation we made just for 60 fps (can’t dispolqy more values changing per second).
If we want render by layer-oriented scheme, so we need some way to save objects and layers what wasn’t saved across for frames-calculating, ehere it wasn’t changed (i know i write some awesome termins, but forgive me - is not my native language). This solution in monogame was of course RenderTarget2D and GraphicsDevice.SetRenderTarget() method.
So, now we in Update() method do all our calculations per layer and store updated layers in layerslist, and in Draw() we just “merge” in proper order and coordinates results from Update() , (It was a strange selection, but our host didn’t switch RenderTarget in Draw() method, so we must do that just in Update() method)
And now we saving each user drawing figures (like lines, rectangles and else) in separate layer (RenderTarget2D) so now i have situation, when part of entire image can blink. So i want tu reduce GPU time on my chart for more efficiency working.
Now it makes sense why they can blink. Use 2 renderTrgets to draw onto, one at start, then when you have to switch continue using the old one until the new one is ready.
ie.
RenderTarget2D target;
void Update()
{
var newTarget = new RenderTarget2D();
//stuff
target = newTarget;
}
void Draw()
{
//Draw target
}
Hmm, we did right like this, but.
We draw also when data source for part of graphics was changed. So, if we see, that new data comes, we re-render part of image (Some RenderTarget2D from a list). And again we merge it when Draw() calls.