By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
443,665 Members | 1,258 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 443,665 IT Pros & Developers. It's quick & easy.

VB2005 timing/speed problem

P: n/a
I have a real timing problem. This involves getting data from a USB device
via an ActiveX dll and drawing trace lines on the screen via a UserControl.

The USB device sends six sets of pixel info so twelve lines have to be drawn
on the screen. The first line drawn blacks out a previously drawn line. The
second line drawn is from the current data. After this is repeated six
times, the program queries the USB device for the next six sets of pixel
data.

The problem is, the USB device, operating in real time, is trying to send
the next set of data before the Host has completed work on the previous set
of data. The problem is so bad that the VB2005 version is operating at 1.5
Heart beats per minute whereas the original VB6 version would be operating
at 75 Heart beats per minute (50 times faster).

The problem could be the marshaling of calls to the COM ActiveX dll or the
drawing time to the screen (or both).

My question today deals with the drawing of the lines. As shown below,
drawing to the screen is via a UserControl. How much faster would it be if I
drew directly to the screen ?

GalenS

All variables below are correctly dimensioned. No internal conversions from
one type to another.

IN MODULE. CALL TO DRAWING SUB, SUB DECLARATION, TYPICAL CALLS TO USER
CONTROL PICTDRAW.

Call LeftRight(frmSweep.PictDraw, Quan)

Public Sub LeftRight(ByRef Obj As PictDraw, ByVal Quan As Short)

For Inner = 0 To NumChns - 1 Step 1
ArgY1 = PrevAry(Inner, Index + Gap)
ArgY2 = PrevAry(Inner, Index + Gap + 1)
Obj.DoLine(ArgX1, ArgY1, ArgX2, ArgY2, glngColors(1))
ArgY2 = PlotAry(Inner, Index + 1)
ArgY1 = PlotAry(Inner, Index)
Obj.DoLine(ArgX3, ArgY1, ArgX4, ArgY2, glngColors(Inner +
4))
Next Inner

USER CONTROL PICTDRAW. SETTING BACKCOLOR SETS UP THE GRAPHICS. VARIABLES ARE
PUBLIC IN A MODULE AS SHOWN AT BOTTOM.

Public Property PictBackColor() As Color
Get
Return BackCol
End Get
Set(ByVal value As Color)
BackCol = value
Panel1.BackColor = value
Me.BackColor = value
If Not Skipflg Then
g = Panel1.CreateGraphics
Bmp = New Bitmap(Panel1.Width, Panel1.Height, g)
g.Dispose()
g = Graphics.FromImage(Bmp)
p = New Pen(Color.Cyan)
f = Me.Font
Skipflg = True
Else
g.Clear(BackCol)
End If
End Set
End Property

tflg is False

Protected Overrides Sub OnPaint(ByVal e As PaintEventArgs)
MyBase.OnPaint(e)
e.Graphics.DrawImage(Bmp, e.ClipRectangle, e.ClipRectangle,
GraphicsUnit.Pixel)
If tflg Then
e.Graphics.DrawImage(tbmp, New Rectangle(0, 0, tbmp.Width,
tbmp.Height), 0, 0, _
tbmp.Width, tbmp.Height, GraphicsUnit.Pixel, ia)
End If
End Sub
Public Sub DoLine(ByVal X1 As Integer, ByVal Y1 As Integer, ByVal X2 As
Integer, _
ByVal Y2 As Integer, ByVal value As Color)
p.Color = value
g.DrawLine(p, X1, Y1, X2, Y2)
Me.Invalidate()
End Sub

Private Sub DoEllipse()
g.DrawEllipse(p, X1, Y1, 1, 1)
Me.Invalidate()
End Sub

Module Module1
Public g As Graphics
Public p As Pen
Public f As Font
Public Bmp As Bitmap
Public Skipflg As Boolean
Public tg As Graphics
Public tp As Pen
Public tf As Font
Public tbmp As Bitmap
Public tflg As Boolean
Public ia As ImageAttributes
End Module
May 5 '06 #1
Share this Question
Share on Google+
4 Replies


P: n/a
Hello,

For faster speed of drawing the lines, you may consider the Windows
platform API directly, or DirectX, instead of GDI+ in .NET. Also, you may
consider add a "queue" before your USD device and your .NET application:
USD device send data to the "queue" object in real time, "queue" save the
data temporarily and your .NET application retrieve data from "queue" based
on its speed.

Regards,

Luke Zhang
Microsoft Online Community Support

==================================================
When responding to posts, please "Reply to Group" via your newsreader so
that others may learn and benefit from your issue.
==================================================

(This posting is provided "AS IS", with no warranties, and confers no
rights.)

May 8 '06 #2

P: n/a
Luke,

Do you think that there are humans who can see real pixel changing on a
screen. I would go to the queing as you suggested of the data than trying to
resolve the screen problem.

The queue class in Net is so deathsimple to use.

http://msdn2.microsoft.com/en-us/lib...ons.queue.aspx

Just my thought, that I wished to share with you.

Cor

"Luke Zhang [MSFT]" <lu******@online.microsoft.com> schreef in bericht
news:AH**************@TK2MSFTNGXA01.phx.gbl...
Hello,

For faster speed of drawing the lines, you may consider the Windows
platform API directly, or DirectX, instead of GDI+ in .NET. Also, you may
consider add a "queue" before your USD device and your .NET application:
USD device send data to the "queue" object in real time, "queue" save the
data temporarily and your .NET application retrieve data from "queue"
based
on its speed.

Regards,

Luke Zhang
Microsoft Online Community Support

==================================================
When responding to posts, please "Reply to Group" via your newsreader so
that others may learn and benefit from your issue.
==================================================

(This posting is provided "AS IS", with no warranties, and confers no
rights.)

May 8 '06 #3

P: n/a
I have tried writing directly to the screen. No double buffering, etc. The
results were just perceptively better.

I think the problem is the marshaling of the data to and from the ActiveX
dll. That plus the fact that after calling into the dll, I have to wait for
the data to return so I can write to the screen. Incidentally I am now
recieving six sets of pixel data for every call. The human eye can't tell
the difference.

If I could figure out how to make a callback (or notification) from the
ActiveX dll I could run the dll in another thread during the data collection
time. Then the main thread just has to grab the data, in packets, and
display to screen. This separate thread would then run full blast while
talking to the USB device.

So that's two items. How to start and stop a new thread and how to make a
notification from an ActiveX dll.

GalenS
"Luke Zhang [MSFT]" <lu******@online.microsoft.com> wrote in message
news:AH**************@TK2MSFTNGXA01.phx.gbl...
Hello,

For faster speed of drawing the lines, you may consider the Windows
platform API directly, or DirectX, instead of GDI+ in .NET. Also, you may
consider add a "queue" before your USD device and your .NET application:
USD device send data to the "queue" object in real time, "queue" save the
data temporarily and your .NET application retrieve data from "queue"
based
on its speed.

Regards,

Luke Zhang
Microsoft Online Community Support

==================================================
When responding to posts, please "Reply to Group" via your newsreader so
that others may learn and benefit from your issue.
==================================================

(This posting is provided "AS IS", with no warranties, and confers no
rights.)

May 8 '06 #4

P: n/a
For marsahll a callback, you may refer to this article:

How to: Marshal Callbacks and Delegates Using C++ Interop
http://msdn2.microsoft.com/en-us/library/367eeye0.aspx

Regards,

Luke Zhang
Microsoft Online Community Support

==================================================
When responding to posts, please "Reply to Group" via your newsreader so
that others may learn and benefit from your issue.
==================================================

(This posting is provided "AS IS", with no warranties, and confers no
rights.)

May 10 '06 #5

This discussion thread is closed

Replies have been disabled for this discussion.