Re: OnPaint Function Issue

Tech-Archive recommends: Speed Up your PC by fixing your registry

Bob,

Thanks for your recent assistance and I will let you know how things progress.

Regards

Andrew.

"Bob Powell [MVP]" wrote:

> Answers inline...
>
> --
> Bob Powell [MVP]
> Visual C#, System.Drawing
>
> Find great Windows Forms articles in Windows Forms Tips and Tricks
> http://www.bobpowell.net/tipstricks.htm
>
> Answer those GDI+ questions with the GDI+ FAQ
> http://www.bobpowell.net/faqmain.htm
>
> All new articles provide code in C# and VB.NET.
> Subscribe to the RSS feeds provided and never miss a new article.
>
>
>
>
>
> "Andrew" <Andrew@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
> news:9E0F4D45-F722-4332-AC7B-246E533CFE2E@xxxxxxxxxxxxxxxx
> > Bob,
> >
> > Upon reflection on your response, can I ask why it is such a last resort
> > to
> > use the g.GetHdc() function when using GDI+ ?
> >
> > (Let me reiterate that I am indeed going to follow your advise and pursue
> > GDI+ and its double buffering features.)
> >
> > I am however interested in undestanding the differences between the double
> > buffering ie GDI+ vs GDI. (Is the GDI+ double buffering software based
> > compared to GDI which appears to involve writing directly to memory ?)
>
> GDI doesn't have a concept of double buffering. To do this task you need to
> create an in-memory bitmap and write to it before blitting it to the screen
> so its manual all the way. GDI+ itself doesn't do double buffering either.
> What is available is a system built into Windows Forms that manages an
> in-memory bitmap that is used as a drawing target for the OnPaint override.
> The bitmap is blitted to the screen at the end of the draw cycle.
>
> >
> > Does g.GetHdc() not return a handle to the graphic object's underlying
> > device context hence providing for a performance increase ?
>
> Yes, but with an hDC you can only use GDI drawing commands so no
> antialiasing, no nice coordinate systems and rudimentary transformation
> matrices with everything based on integer math.
>
> >
> > So I suppose my question is that in terms of drawing speed, would the
> > levels of increased performance offered by the technologies that we have
> > been discussing be :
> >
> > 1. Use GDI + and its inherent double buffering
>
> This reduces flicker. there is no performance increase.
>
> > 2. Use GDI+ and where greatest performance is needed , call g.GetHdc() and
> > use the BitBlt and StretchBit type API functions. Appreciating that you
> > can
> > not mix your calls to GDI and GDI+ drawing functions.
>
> Using the GDI based hardware accellerated blitting is a known performance
> boost.
>
> >
> > 3. For the fastest possible speed make calls to the DirectX API's from the
> > managed
> > code. (I thought that DirectX was only for 3D (is it really also used
> > for 2D ?).
>
> Direct3D is only a small part of DirectX. DirectDraw is 2D and uses
> extremely fast blitting (although quirky) and automatic buffer flipping. I
> have written C# applications that perform hundreds of frames per second but
> the quirkiness of using DirectDraw can be annoying. You have to really need
> the performance to want to do it.
>
> >
> > Regards
> >
> > Andrew
> > "Bob Powell [MVP]" wrote:
> >
> >> You really need to be reading the GDI+ FAQ.
> >>
> >> GDI+ uses Bitmap objects for in-memory image manipulation, Windows Forms
> >> does automatic double buffering, you don't need to be using interop and
> >> GDI
> >> blitting unless you are doing some very fast frame updates and even then
> >> it
> >> would be better to use the managed directx libraries.
> >>
> >> From what you ask I think you're working too hard. Take a step back and
> >> find
> >> out what GDI+ can do for you before going off on a tangent with complex
> >> interop scenarios.
> >>
> >> --
> >> Bob Powell [MVP]
> >> Visual C#, System.Drawing
> >>
> >> Find great Windows Forms articles in Windows Forms Tips and Tricks
> >> http://www.bobpowell.net/tipstricks.htm
> >>
> >> Answer those GDI+ questions with the GDI+ FAQ
> >> http://www.bobpowell.net/faqmain.htm
> >>
> >> All new articles provide code in C# and VB.NET.
> >> Subscribe to the RSS feeds provided and never miss a new article.
> >>
> >>
> >>
> >>
> >>
> >> "Andrew" <Andrew@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
> >> news:5E201E83-09B0-4CC9-B347-DEF3156D2272@xxxxxxxxxxxxxxxx
> >> > Bob,
> >> >
> >> > I assume that by double-buffering that you mean using the GDI type
> >> > Windows
> >> > API functions like BitBlt where all drawing is done to a off sreen
> >> > memory
> >> > device
> >> > context and then "blasted" to the device context that represents the
> >> > drawing
> >> > surface of the view. YES, OK
> >> >
> >> > I actually started out the coding process of the graphics module ,
> >> > thinking
> >> > along the
> >> > lines (sorry) of memory device contexts, GetHdc() and using the GDI
> >> > draw
> >> > methods.
> >> >
> >> > Then I became wooed by the relative ease of the GDI + , until the
> >> > reported
> >> > drawing
> >> > speed issue.
> >> >
> >> > As far as I am aware there are no memory device contexts or bitblitting
> >> > technology
> >> > available in GDI+ , is this correct ?
> >> >
> >> > Therefore are you advising that I get a handle to the device context
> >> > that
> >> > underlies the graphics object , and use memory device context and
> >> > bitblitting
> >> > type methods
> >> > for my drawing routines ?
> >> >
> >> > I do not have a problem with this approach (as I have written much of
> >> > this
> >> > type of code and commented it out when I started using GDI+ methods).
> >> >
> >> > If I am correct in the above, can I suggest to you that for performance
> >> > based graphics operations( like all of the graphics routines in my
> >> > app) -
> >> > GDI+ is completely unsuitable despite the apparent ease of the method
> >> > calls.
> >> >
> >> > The suggested approach seems to involve usage of the GDI technologies
> >> > which
> >> > were supposed to have been superceded by GDI+.
> >> >
> >> > I appreciate your wealth of experience on these matters, and I am not
> >> > being
> >> > disrespectful, I need to get a clear direction regarding the technology
> >> > that
> >> > will be
> >> > best suited to the graphics module of this application - Is the GDI
> >> > the
> >> > way
> >> > to go ?
> >> >
> >> > Thanks for your tips that you expanded upon, regarding the performance
> >> > issue.
> >> >
> >> > Andrew.
> >> >
> >> >
> >> > "Bob Powell [MVP]" wrote:
> >> >
> >> >> Paint coming along several times is a long standing feature of
> >> >> Windows.
> >> >>
> >> >> You will be able to reduce flickering across all of your application
> >> >> by
> >> >> double-buffering the drawing. (consider this as an answer to your
> >> >> subsequent
> >> >> question too)
> >> >>
> >> >> To improve performance as much as possible ensure that you test
> >> >> bounding
> >> >> boxes of objects that may be panned outside of your view and do not
> >> >> draw
> >> >> them if they are off-page. Make sure that when you use images or
> >> >> blitting
> >> >> of
> >> >> in-memory bitmaps that they use 32BppArgb pixel formats. Make sure
> >> >> that
> >> >> OnPaintBackground isn't uneccesarily whitewashing the background..
> >> >> Pixels
> >> >> mean time.
> >> >>
> >> >> Use matrices to pan or zoom the canvas. The calculations are being
> >> >> done
> >> >> in
> >> >> the pipeline anyway so modifying a matrix adds no processing time to
> >> >> the
> >> >> drawing at-all. Scaling and moving objects using calculations based on
> >> >> the
> >> >> autoscroll positions will add time to the drawing.
> >> >>
> >> >> --
> >> >> Bob Powell [MVP]
> >> >> Visual C#, System.Drawing
> >> >>
> >> >> Find great Windows Forms articles in Windows Forms Tips and Tricks
> >> >> http://www.bobpowell.net/tipstricks.htm
> >> >>
> >> >> Answer those GDI+ questions with the GDI+ FAQ
> >> >> http://www.bobpowell.net/faqmain.htm
> >> >>
> >> >> All new articles provide code in C# and VB.NET.
> >> >> Subscribe to the RSS feeds provided and never miss a new article.
> >> >>
> >> >>
> >> >>
> >> >>
> >> >>
> >> >> "Andrew" <Andrew@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
> >> >> news:46D17741-1201-4D5F-A559-5C2B836282C6@xxxxxxxxxxxxxxxx
> >> >> > Hello,
> >> >> >
> >> >> > I have a couple of drawing routines that involve drawing basic
> >> >> > shapes
> >> >> > and
> >> >> > I
> >> >> > am
> >> >> > calling these routines from the my views OnPaint handler .
> >> >> >
> >> >> > This view class (BuildingView), is a derivative of a generic view
> >> >> > class
> >> >> > (LayerView), which is itself a TabPage derivative).
> >> >> >
> >> >> > Other views (ColumnsView,FloorView,OpeningsView) are arranged on a
> >> >> > TabControl
> >> >> > and any one can be made active by simply clicking on the appropriate
> >> >> > Tab.
> >> >> >
> >> >> > Take Building View as an example.
> >> >> >
> >> >> > BuildingView's OnPaint handler calls its base class
> >> >> > OnPaint(LayerView)
> >> >> > which
> >> >> > in turn
> >> >> > calls TabPage OnPaint.
> >> >> >
> >> >> > LayerView OnPaint determines if scrolling is needed by setting
> >> >> > AutoScrollMinSize.
> >> >> >
> >> >> > The problem is that first time BuildingView is displayed, my drawing
> >> >> > routines(called from BuildingView) are being called twice resulting
> >> >> > in
> >> >> > a
> >> >> > flickering effect.
> >> >> >
> >> >> > No double drawing occurs when the BuildingView is redisplayed after
> >> >> > having
> >> >> > displayed a different view in the TabControl.
> >> >> >
> >> >> > I do realise that a forms OnPaint handler is called many times ie
> >> >> > form
> >> >> > creation, form resizing, form display...
> >> >> >
> >> >> > How do I prevent my drawing routines from being executed several
> >> >> > times,
> >> >> > the
> >> >> > first
> >> >> > time the view/form is displayed ?
> >> >> >
> >> >> >
> >> >> > Sorry for the complex explanation.
> >> >> >
> >> >> > Any comments would be well regarded.
> >> >> >
> >> >> > Thanks
> >> >> >
> >> >> > Andrew.
> >> >> >
> >> >>
> >> >>
> >> >>
> >>
> >>
> >>
>
>
>
.

Quantcast