Re: 2D graphics & speed quest

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

"Mike D Sutton" <EDais@xxxxxxxx> wrote in message news:u1IADOZZGHA.3448@xxxxxxxxxxxxxxxxxxxxxxx

Hmm, I guess there may be some overhead there based on the graphics
driver but for the most part apart from pre-calculation of lookup tables
and allocation of buffers I don't see what analysis would bee to be made
since, assuming the destination is a DDB, the data is already in the most
efficient device dependant form and managed by the driver. There would
of course be some overhead to calling into a DLL each time though.
If you know of any literature on the subject to the contrary then I'd be interested in finding out more though.

Hmm, no literature I'm afraid. I usually give far more credence to empirical evidence, which is usually the most reliable anyway and which tells me that repeatedly calling an API routine to perform a certain task is almost always very much slower than calling a similar API routine that gets the same job "done in one go".

PolyLine() does however appear to be slightly more efficient at
clipping large areas of the dataset though which may have skewed
your previous test results? Wait, you did test before posting that
previous statement, right?..

My previous test results were not skewed by anything, although I think your own might have been? And yes, I did test before posting, which incidentally appears to be more than you did or you would almost certainly have noticed the problem with the PolyLine declaration in the code you posted, right?..

This is not necessarily correct.. I'm seeing LineTo() taking half the
time to draw the same shape as PolyLine(). To be honest these results
were a surprise to me too, I would have agreed with you that
PolyLine() _should_ be faster especially since we've got the
overhead of calling a DLL for each line segment:

Actually, PolyLine() _is_ faster. It's just that your test code causes other things to happen that are not being taken into account. Remember, I'm talking about the speed of PolyLine versus the equivalent bunch of LineTo calls, and so I'm only interested in the time _those specific routines_ take to draw their output, without anything else getting in the way of the results. The problem with the code you posted is that a whole bunch of display refreshes is going on at the same time, which tends to swamp things. If you use your exact same code but set the Form's Autoredraw property to True you will see an entirely different result. Both of them (PolyLine and the bunch of LineTo stuff) will of course be very much faster than they were before (because we've got the display refreshes out of the way) and in addition you'll see that PolyLine is actually very much faster than the bunch of LineTo calls. Most people do most of their drawing to offscreen buffers anyway, and only dump the result to the screen when it is done, so drawing to an offscreen buffer is a perfectly valid way of testing the speed of these things. At this end I'm getting a massive speed increase all round (as you would of course expect) and I'm seeing PolyLine about _a hundred times faster_ than the equivalent bunch of LineTo statements. Here's your own code but using Autoredraw = True. Let me know what you get at your end.

Hope this helps.

Mike

'*** Using: http://edais.mvps.org/Code/Libraries/Utility/clsStopWatch.cls
Private Declare Function MoveToEx Lib "GDI32.dll" (ByVal hDC As Long, _
ByVal X As Long, ByVal Y As Long, ByRef lpPoint As Any) As Long
Private Declare Function LineTo Lib "GDI32.dll" (ByVal hDC As Long, _
ByVal X As Long, ByVal Y As Long) As Long
Private Declare Function Polyline Lib "GDI32.dll" (ByVal hDC As Long, _
ByRef lpPoint As PointAPI, ByVal nCount As Long) As Long

Private Type PointAPI
X As Long
Y As Long
End Type

Private Sub Form_Click()
Me.AutoRedraw = True
Dim MyPts() As PointAPI
Dim LoopPts As Long
Dim StopWatch As clsStopWatch
Dim LoopDraw As Long
Dim Times(0 To 1) As Double

Const NumPts As Long = 1000
Const NumDraw As Long = 100

' Generate a random polygon
ReDim MyPts(0 To NumPts - 1) As PointAPI
For LoopPts = 0 To NumPts - 1
MyPts(LoopPts).X = Rnd() * 1000
MyPts(LoopPts).Y = Rnd() * 1000
Next LoopPts

Set StopWatch = New clsStopWatch

Call StopWatch.StartTimer ' Profile PolyLine()
For LoopDraw = 0 To NumDraw - 1
Call Polyline(Me.hDC, MyPts(0), NumPts)
Next LoopDraw
Call StopWatch.StopTimer
Times(0) = StopWatch.Interval
Me.Refresh
Call StopWatch.StartTimer ' Profile MoveToEx()/LineTo()
For LoopDraw = 0 To NumDraw - 1
Call MoveToEx(Me.hDC, MyPts(0).X, MyPts(0).Y, ByVal 0&)

For LoopPts = 1 To NumPts - 1
Call LineTo(Me.hDC, MyPts(LoopPts).X, MyPts(LoopPts).Y)
Next LoopPts
Next LoopDraw
Call StopWatch.StopTimer
Times(1) = StopWatch.Interval
Me.Refresh
Set StopWatch = Nothing

' Display results
Call MsgBox( _
"PolyLine(): " & Format$(Times(0), "0.00") & vbCrLf & _
"LineTo(): " & Format$(Times(1), "0.00"))
End Sub








.

Relevant Pages

  • Re: 2D graphics & speed quest
    ... 3600 for both LineTo and Polyline. ... LineTo calls, and so I'm only interested in the time _those specific ... Private Declare Function MoveToEx Lib "GDI32.dll" (ByVal hDC As Long, ... Dim MyPts() As PointAPI ...
    (microsoft.public.vb.general.discussion)
  • Re: 2D graphics & speed quest
    ... LineTo calls, and so I'm only interested in the time _those specific ... bunch of display refreshes is going on at the same time, ... anything PolyLine() should have the upper hand since it could wait until ... Most people do most of their drawing to offscreen ...
    (microsoft.public.vb.general.discussion)
  • Re: 2D graphics & speed quest
    ... PolyLine(): 7.8 LineTo(): 986.2 ... the drawing is taking place). ... drawing to the displayed Form or Picture Box is the best option if you ...
    (microsoft.public.vb.general.discussion)
  • Re: 2D graphics & speed quest
    ... PolyLine(): 2.6 LineTo(): 1327.0 ... AutoDraw = False No Button ... However, for PolyLine to achieve such a fast speed and for it to be more or less guaranteed on most systems you need to be drawing to the displayed Form or Picture Box directly and there needs to be no "holes" in the clipping region. ...
    (microsoft.public.vb.general.discussion)