.NET slow graphics
-
Sorry, my fault I missed the g vs. memg variable. :-O Did you try only redrawing the Bitmap when the data changes and let DrawImage() scale the image to the size of the window? That way your plotting code would not execute during resizing of the window.
led mike
-
Why is the .NET graphics in windows forms app is so slow, manualy ploting some N points line segments using double buffer takes considerable time compared to say builder compiled app? Is there special tips to make it faster.
9ine
The short answer is the .NET GDI runs in a way which precludes parts of it from being accelerated by a graphics card. The second issue is the extensive marshalling that goes on between .NET and the Win32 GDI layer.
Anyone who thinks he has a better idea of what's good for people than people do is a swine. - P.J. O'Rourke
-
The short answer is the .NET GDI runs in a way which precludes parts of it from being accelerated by a graphics card. The second issue is the extensive marshalling that goes on between .NET and the Win32 GDI layer.
Anyone who thinks he has a better idea of what's good for people than people do is a swine. - P.J. O'Rourke
Thats very silly, having so much of the product developed and failed to beat simple builder C++ application??? Consider even compilation times! I noticed that builder compiled app 1D plotting runs faster on modern video cards compared to simple ones from the last century. I think there is another reason is the Bitmap object itself. In builder you can ajust bitmap canvas properties by simply adjusting its size without deleting the bitmap! However in .NET Bitmap object it can be created only of the fixed size! and you can not change its dimensions during run-time. The possible sollution is to delet it and allocate a new one to fit the form during the resize method. But in __gc compiled resources you can not delete them :-) the garbage cleaner do it. So if rely on the garbage cleaner to delete all the allocated Bitmaps during form resizing events you end up without free mem :-) Very silly.
9ine
-
Thats very silly, having so much of the product developed and failed to beat simple builder C++ application??? Consider even compilation times! I noticed that builder compiled app 1D plotting runs faster on modern video cards compared to simple ones from the last century. I think there is another reason is the Bitmap object itself. In builder you can ajust bitmap canvas properties by simply adjusting its size without deleting the bitmap! However in .NET Bitmap object it can be created only of the fixed size! and you can not change its dimensions during run-time. The possible sollution is to delet it and allocate a new one to fit the form during the resize method. But in __gc compiled resources you can not delete them :-) the garbage cleaner do it. So if rely on the garbage cleaner to delete all the allocated Bitmaps during form resizing events you end up without free mem :-) Very silly.
9ine
-
Thats very silly, having so much of the product developed and failed to beat simple builder C++ application??? Consider even compilation times! I noticed that builder compiled app 1D plotting runs faster on modern video cards compared to simple ones from the last century. I think there is another reason is the Bitmap object itself. In builder you can ajust bitmap canvas properties by simply adjusting its size without deleting the bitmap! However in .NET Bitmap object it can be created only of the fixed size! and you can not change its dimensions during run-time. The possible sollution is to delet it and allocate a new one to fit the form during the resize method. But in __gc compiled resources you can not delete them :-) the garbage cleaner do it. So if rely on the garbage cleaner to delete all the allocated Bitmaps during form resizing events you end up without free mem :-) Very silly.
9ine
9ine wrote:
In builder you can ajust bitmap canvas properties by simply adjusting its size without deleting the bitmap!
Some helper class is doing this, and probably deleting/recreating the bitmap in the background. Bitmaps are a fixed size, like any allocation of memory.
9ine wrote:
. But in __gc compiled resources you can not delete them
You can Dispose them, which is the same thing, the unmanaged resource is cleaned up.
Christian Graus - Microsoft MVP - C++ Metal Musings - Rex and my new metal blog
-
it is not possible, we need to plot a resized version of the plot like in magnifying the 1D plot by means of incresing size of the canvas
9ine
-
Thats very silly, having so much of the product developed and failed to beat simple builder C++ application??? Consider even compilation times! I noticed that builder compiled app 1D plotting runs faster on modern video cards compared to simple ones from the last century. I think there is another reason is the Bitmap object itself. In builder you can ajust bitmap canvas properties by simply adjusting its size without deleting the bitmap! However in .NET Bitmap object it can be created only of the fixed size! and you can not change its dimensions during run-time. The possible sollution is to delet it and allocate a new one to fit the form during the resize method. But in __gc compiled resources you can not delete them :-) the garbage cleaner do it. So if rely on the garbage cleaner to delete all the allocated Bitmaps during form resizing events you end up without free mem :-) Very silly.
9ine
I wonder if builder is using a DIB Section below the surface.
Anyone who thinks he has a better idea of what's good for people than people do is a swine. - P.J. O'Rourke
-
9ine wrote:
In builder you can ajust bitmap canvas properties by simply adjusting its size without deleting the bitmap!
Some helper class is doing this, and probably deleting/recreating the bitmap in the background. Bitmaps are a fixed size, like any allocation of memory.
9ine wrote:
. But in __gc compiled resources you can not delete them
You can Dispose them, which is the same thing, the unmanaged resource is cleaned up.
Christian Graus - Microsoft MVP - C++ Metal Musings - Rex and my new metal blog
dispose is of no help. consider resizing a window it is about dozen resize messages and you end up with no free mem. it does not delete the Bitmap object immediatly once executed!? Thats the great disadvantage of .NET objects you can not resize them once allocated nor delete them :-) Simple Borland Builder posses all these features, the only disadvantage is its debugging process, VC provides more useful quickwatch.
9ine
-
I wonder if builder is using a DIB Section below the surface.
Anyone who thinks he has a better idea of what's good for people than people do is a swine. - P.J. O'Rourke
What is it. and is it useful? The problem is to render promptly floating array of data to a window. Once you created bitmap in Builder you can alter its size without deleting it. So without a flick you can plot the data you want. .NET graphics is good for ploting image files not some floating array to fit a window. Probably the only solution to a lame .NET graphics is opengl one?
9ine
-
dispose is of no help. consider resizing a window it is about dozen resize messages and you end up with no free mem. it does not delete the Bitmap object immediatly once executed!? Thats the great disadvantage of .NET objects you can not resize them once allocated nor delete them :-) Simple Borland Builder posses all these features, the only disadvantage is its debugging process, VC provides more useful quickwatch.
9ine
9ine wrote:
consider resizing a window it is about dozen resize messages and you end up with no free mem. it does not delete the Bitmap object immediatly once executed!?
Like I said, you can delete the bitmap every time, Dispose does this.
9ine wrote:
Thats the great disadvantage of .NET objects you can not resize them once allocated nor delete them
NOR DOES BORLAND BUILDER !!!
9ine wrote:
Simple Borland Builder posses all these features
You're just plain wrong. Borland cannot change the nature of Windows, it cannot create a world where you can resize a bitmap without deallocating and reallocating it. All it can do is hide the facts from you.
Christian Graus - Microsoft MVP - C++ Metal Musings - Rex and my new metal blog
-
9ine wrote:
consider resizing a window it is about dozen resize messages and you end up with no free mem. it does not delete the Bitmap object immediatly once executed!?
Like I said, you can delete the bitmap every time, Dispose does this.
9ine wrote:
Thats the great disadvantage of .NET objects you can not resize them once allocated nor delete them
NOR DOES BORLAND BUILDER !!!
9ine wrote:
Simple Borland Builder posses all these features
You're just plain wrong. Borland cannot change the nature of Windows, it cannot create a world where you can resize a bitmap without deallocating and reallocating it. All it can do is hide the facts from you.
Christian Graus - Microsoft MVP - C++ Metal Musings - Rex and my new metal blog
-
What is it. and is it useful? The problem is to render promptly floating array of data to a window. Once you created bitmap in Builder you can alter its size without deleting it. So without a flick you can plot the data you want. .NET graphics is good for ploting image files not some floating array to fit a window. Probably the only solution to a lame .NET graphics is opengl one?
9ine
http://www.3dsoftware.com/Programming/WindowsAPI/DIB_Section/[^] Realize that builder isn't just alerting the size; it is recreating bitmaps below the surface and copying the old data to the new one. Using DIB Sections you could do this copy fairly quickly. One solution is to write the code you want at the Win32 layer with C++/CLI. Another is to look around and see if any company is selling a toolkit that does what you want. I'd also suggest working with .NET some more and thoroughly understanding the graphics layer to make sure there isn't a great third solution I haven't thought of. (Oh, and you may need to rethink how you are doing your application. Perhaps a different algorithm on your part would make a purely .NET solution viable.)
Anyone who thinks he has a better idea of what's good for people than people do is a swine. - P.J. O'Rourke
-
then the builder is more succesfull in hiding windows facts from me than the native VC does. dispose results in delayed memory deallocation
9ine
Yes, that is precisely what a wrapper does. MFC doesn't wrap bitmaps in a way to hide these facts. It's no different to std::vector or CArray. Using those, you'd never guess that you can't create an array and then just keep adding stuff to it without it having to reallocate memory. The class hides this task from you.
Christian Graus - Microsoft MVP - C++ Metal Musings - Rex and my new metal blog