When to use buffered graphics
When to use buffered graphics
When to use buffered graphics
When to use buffered graphics
When to use buffered graphics
When to use buffered graphics When to use buffered graphics When to use buffered graphics When to use buffered graphics When to use buffered graphics When to use buffered graphics When to use buffered graphics When to use buffered graphics
When to use buffered graphics When to use buffered graphics
When to use buffered graphics
Go Back  Xtreme Visual Basic Talk > > > When to use buffered graphics


Reply
 
Thread Tools Display Modes
  #1  
Old 02-26-2013, 04:18 PM
CodeCruncher CodeCruncher is offline
Junior Contributor
 
Join Date: Jul 2006
Posts: 355
Default When to use buffered graphics


This is a very generic question so I am not expecting an overly complicated answer, but is there a general rule of thumb when to use buffered graphics and when not to?

I have recently added buffered graphics to a project I am working on and I now wonder if it was really necessary.

I figure when you are using a timer and the graphic is constantly moving like bouncing ball or a rotating cube I can see how you might want to keep the graphic in a buffer, but if the image is stationary on screen and is only moved when the mouse is dragged is it really necessary?
Reply With Quote
  #2  
Old 02-26-2013, 04:25 PM
AtmaWeapon's Avatar
AtmaWeaponWhen to use buffered graphics AtmaWeapon is offline
Fabulous Florist

Forum Leader
* Guru *
 
Join Date: Feb 2004
Location: Austin, TX
Posts: 9,500
Default

In 10 years of developing custom controls, I have never used that particular class. I think 2011 was the first time I ever even heard of the class.

Now I /have/ managed my own in-memory bitmap which I then draw to the screen all at once. And I /have/ done work to calculate invalidation rectangles and only redraw within them. And I've used the "optimized double buffer" window styles. But the last time I tried to use the BufferedGraphics class it made my head hurt.

On a side note, it feels like if you'd have started learning C and a graphics library at about the same time you started these explorations into graphics via VB .NET, you'd have already accomplished your goal of rendering 3D surfaces in a space. Short of WPF 3D (which has its own limitations and performance concerns and IMO is inappropriate for developing a game) VB .NET leaves you to build your own 3D rendering or find a usable library.
__________________
.NET Resources
My FAQ threads | Tutor's Corner | Code Library
I would bet money 2/3 of .NET questions are already answered in one of these three places.
Reply With Quote
  #3  
Old 02-26-2013, 05:15 PM
CodeCruncher CodeCruncher is offline
Junior Contributor
 
Join Date: Jul 2006
Posts: 355
Default

Half the problem is coming into 3d graphics I had no idea how it worked or what it did, so I’m not sure doing it in C would have made it any easier. But after going through the exercise of learning how to do double buffered graphics, I now think that an in memory bitmap method might be a much more sensible solution.

I already have bits and pieces of some sample code, so I don’t think it will be too hard to adapt. What I needed to do was understand the concept of rendering the drawing in memory first. I think I have moved a long way towards that now.

Here's a bit of code from surfR2911 that should get me back on track.

Code:
Public Function DrawCube(ByVal drawOrigin As Point) As Bitmap
  'Get the bounds of the final bitmap
  Dim bounds As Rectangle = getDrawingBounds()
  bounds.Width += drawOrigin.X
  bounds.Height += drawOrigin.Y
  Dim finalBmp As New Bitmap(bounds.Width, bounds.Height) 'new bitmap just "made up" in memory
  Dim g As Graphics = Graphics.FromImage(finalBmp) 'graphic object from a bitmap without an image ----important!!!!!
  g.SmoothingMode = SmoothingMode.AntiAlias
  'some other code here..    
  If m_drawWires Then
      g.DrawLine(Pens.Black, faces(i).Corners2D(0), faces(i).Corners2D(1))
      g.DrawLine(Pens.Black, faces(i).Corners2D(1), faces(i).Corners2D(2))
      g.DrawLine(Pens.Black, faces(i).Corners2D(2), faces(i).Corners2D(3))
      g.DrawLine(Pens.Black, faces(i).Corners2D(3), faces(i).Corners2D(0))
    End If
  Next
  Return finalBmp 'returns an image that can be assigned to a picturebox, form or panel
End Function

Last edited by CodeCruncher; 02-26-2013 at 05:22 PM.
Reply With Quote
  #4  
Old 02-26-2013, 05:47 PM
OnErr0r's Avatar
OnErr0rWhen to use buffered graphics OnErr0r is offline
Obsessive OPtimizer

Administrator
* Guru *
 
Join Date: Jun 2002
Location: Debug Window
Posts: 13,774
Default

I dug around the framework and looked at BufferedGraphics some time ago. I'm assuming it's still similar. It wraps the hardware accelerated GDI BitBlt API to draw much faster than GDI+ calls normally can. You're going to get a much higher framerate with it.

http://www.xtremevbtalk.com/showpost...2&postcount=10
__________________
Quis custodiet ipsos custodues.
Reply With Quote
  #5  
Old 02-26-2013, 07:54 PM
CodeCruncher CodeCruncher is offline
Junior Contributor
 
Join Date: Jul 2006
Posts: 355
Default

If you want a refresher passel and others helped out with some good code here Buffered Graphics Class
Reply With Quote
  #6  
Old 02-27-2013, 06:55 AM
Rockoon's Avatar
Rockoon Rockoon is offline
Joseph Koss

* Guru *
 
Join Date: Aug 2003
Location: Unfashionable End
Posts: 3,615
Default

From a theoretical perspective, you should always buffer your rendering unless you want flicker.

From a practical perspective, rendering is often buffered even when you think that it isn't. Pretty much any use of an advanced rendering API with begin/end semantics will be using a offscreen buffer (often called "double buffer") of some kind before the final write to the onscreen buffer.

From a VB.NET perspective, the point of the buffered graphics class is not the same thing as is normally considered when speaking about buffered graphics. The point of this class isnt just to provide an offscreen surface to render to, but to also persist the resulting rendering for long periods of time.

In the case of any sort of interactive or high frame rate rendering, the buffered graphics class is pointless because there is no reason to persist the resulting rendering, but you will still want to code up offscreen buffer semantics to avoid flicker if you arent using an api that provides one.
Reply With Quote
  #7  
Old 02-27-2013, 02:04 PM
hDC_0When to use buffered graphics hDC_0 is offline
Contributor

* Expert *
 
Join Date: Feb 2004
Posts: 559
Default Let's try to wrap things up..

Quote:
Originally Posted by OnErr0r
It wraps the hardware accelerated GDI BitBlt API to draw much faster than GDI+ calls normally can. You're going to get a much higher framerate with it.
Quote:
Originally Posted by Rockoon
From a theoretical perspective, you should always buffer your rendering unless you want flicker.
From a VB.NET perspective..the point of this class isn't just to provide an offscreen surface to render to, but to also persist the resulting rendering for long periods of time.
Yes and yes.
I think the question has been answered.
When should you not use buffered graphics?
When you don't care anything about any of the things that Rockoon and OnErr0r are talking about..

Quote:
I already have bits and pieces of some sample code, so I don’t think it will be too hard to adapt.
What I needed to do was understand the concept of rendering the drawing in memory first. I think I have moved a long way towards that now.
Hopefully you will be moving on past the question of this thread, now that
it looks like passel's BufferGraphics class (from this thread) has been adapted and added\
to version 5 of the Baffle Step Calculator (attached here).

Last edited by hDC_0; 02-27-2013 at 02:36 PM.
Reply With Quote
  #8  
Old 02-27-2013, 03:07 PM
passel's Avatar
passelWhen to use buffered graphics passel is offline
Sinecure Expert

Super Moderator
* Guru *
 
Join Date: Jun 2003
Location: Upstate New York, usa
Posts: 8,024
Default

Quote:
Originally Posted by Rockoon View Post
...
From a VB.NET perspective, the point of the buffered graphics class is not the same thing as is normally considered when speaking about buffered graphics. The point of this class isnt just to provide an offscreen surface to render to, but to also persist the resulting rendering for long periods of time.
I don't think I would call it the point of the class, just a possible side benefit of a possible use of it. On one msdn page it states:
"For more advanced double buffering scenarios, such as animation or advanced memory management, you can use the .NET Framework classes to implement your own double-buffering logic. The class responsible for allocating and managing individual graphics buffers is the BufferedGraphicsContext class."

Now I'm sure everyone agrees that using a more advanced graphics API (i.e. DirectX, OpenGL, etc....) would be ideal, but if you're sticking with the winForm application, my testing has shown multiple benefits to using the BufferedGraphics classes, when needed.

Quote:
Originally Posted by Rockoon View Post
In the case of any sort of interactive or high frame rate rendering, the buffered graphics class is pointless because there is no reason to persist the resulting rendering, but you will still want to code up offscreen buffer semantics to avoid flicker if you arent using an api that provides one.
Not quite pointless, I believe, because of the increased drawing throughput you can acheive within the confines of a winForms application.
Since the following may be verbose, I'll enumerate what I consider benefits first, then the rest can be ignored if not interested.
1. Much less overhead in "flipping" backbuffer to screen, so more time for drawing and faster frame rates, if desired.
2. Drawing and rendering to the screen can be done in a background thread, so no need to Invoke back to the GUI thread (with associated overhead) to update a graphics display.
3. Since you render directly to the screen, you don't need to be restricted to the Paint event, and related messaging overhead, so in speed tests, I've refreshed the screen area of the form over 4000 times a second.

Some quotes from this thread on investigations I did.
"As part of this investigation, I determined that the update from backbuffer to screen was taking a significant chunk of time on this machine.
The method used in the test is to write to a bitmap which the picturebox's .Image object is referencing.
Thus when you do a Refresh on the picturebox, the control will automatically refresh the screen from its Image object.
On this machine, it took 8-10 ms to update the screen from the image (and this isn't full screen, so a bigger window takes even more time), so was chewing up more than 50% of 15.625 ms we had available to run at our max 64hz.
To maintain 64hz, our drawing would have to take 5ms or less.

So, how can we get the backbuffer written to the screen quicker.
I tried several things.
Create a brush from the backbuffer and paint a big filled rectangle with it. Slower.
Create a GDI BitBlt compatible bitmap of the backbuffer and use bitblt. Slower.
Don't associate the bitmap with the Picturebox's Image, but instead use the more traditional
e.Graphics.DrawImage(gameDisplay,0,0)
in the Paint event.
This was actually the same speed as having the control refresh itself from the backbuffer, so between the two, it would probably be better and more acceptable to do the DrawImage in the Paint Event, as it is more in line with the expected .Net practice.

So, I couldn't find a faster method, with the current way the backbuffer was done.
I then decided to look into using the .Net provided class for BackBuffering (the BufferedGraphics class) to see if it using it could cut down on the time to refresh the screen from the BackBuffer."
...
"Well, the good news is that is cut down on the time to get graphics from backbuffer to screen significantly.
On this machine, the refresh now only takes 2-3 ms, vs the 8-10 it was taking before."

In this thread was some investigation which is where the graphic updates are being done in a background thread (no graphics being done from the GUI thread) and the speed test showed updates of thousands of times per second on some machines. I've gotten a newer business machine since that thread, an HP EliteBook 8470p, which is not necessarily a "hot" machine, but it does have an Intel i5 and the Space Invaders test posts close to the same numbers (FPS 4000+) in the speed tests.
__________________
There Is An Island Of Opportunity In The Middle of Every Difficulty.
Miss That, Though, And You're Pretty Much Doomed.
Reply With Quote
  #9  
Old 02-27-2013, 05:46 PM
Rockoon's Avatar
Rockoon Rockoon is offline
Joseph Koss

* Guru *
 
Join Date: Aug 2003
Location: Unfashionable End
Posts: 3,615
Default

Reply With Quote
  #10  
Old 02-27-2013, 08:11 PM
CodeCruncher CodeCruncher is offline
Junior Contributor
 
Join Date: Jul 2006
Posts: 355
Default

Thank you all for the input, so the overwhelming consensus seems that using the double buffer as I have it is not overkill, as I thought it might be. I will leave it as is.
Reply With Quote
Reply


Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)
 
Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off

Forum Jump

Advertisement:





Free Publications
The ASP.NET 2.0 Anthology
101 Essential Tips, Tricks & Hacks - Free 156 Page Preview. Learn the most practical features and best approaches for ASP.NET.
subscribe
Programmers Heaven C# School Book -Free 338 Page eBook
The Programmers Heaven C# School book covers the .NET framework and the C# language.
subscribe
Build Your Own ASP.NET 3.5 Web Site Using C# & VB, 3rd Edition - Free 219 Page Preview!
This comprehensive step-by-step guide will help get your database-driven ASP.NET web site up and running in no time..
subscribe
When to use buffered graphics
When to use buffered graphics
When to use buffered graphics When to use buffered graphics
When to use buffered graphics
When to use buffered graphics
When to use buffered graphics When to use buffered graphics When to use buffered graphics When to use buffered graphics When to use buffered graphics When to use buffered graphics When to use buffered graphics
When to use buffered graphics
When to use buffered graphics
 
When to use buffered graphics
When to use buffered graphics
 
-->