vb vs c++ (graphics programming)

The problem with that is the lines have to be drawn IN ORDER...

So the 2nd line to be drawn may not be the same color as the first.... and would not correctly restructure the picture.

On another note, once the image is drawn though, we could use the byte memory of the image and sucessfully zoom it in or out, or rotate it fast... which I believe was really the only important requirement, and as it stands, i have code that takes 52 secs to draw 5 million lines at 1.5ghz...

If any more performance is needed, then we'll have to step back and take a look at different approaches. If we want the process to take 1 second on a 1ghz machine, then that will allot 25 CPU cycles per each line of a set of 4 million lines. If the process takes one minute, then that will allot 1500 cycles per line. I would have to assume that the line methods and API's are optimized in assembly, and that no further optimization can be achieved. Thus, you would have to find an alternate method to pre-process all of these lines before they are drawn, which is an intriguing problem.

Alright, I found something that would undoubtedly help us with this problem:

The requirement isn't so much that initial load of the picture be fast... but that zooming or rotation be quick to load.

In that respect, I have found a set of API's that seemed they were designed to do just this, not a bltbit stretch or decompress, but a realtime transformation via scale, if its perhaps possible to actually change the line drawing to a worldspace, then we can map the region to be zoomed to display full size of the picturebox without redrawing the lines:

http://msdn.microsoft.com/library/de...dspac_6pm6.asp

So we would draw our 5 million lines to worldspace, then for zooming, we select a portion of that worldspace, and the system transforms that portion to fill the picturebox width and height.

Excellent find; I was just thinking along the lines of how CAD applications work in this area, since they undoubtably (at least the really good ones) have discovered the fastest ways to draw these lines. If someone sends me a section of the datafile (or the whole thing; I have T1 download bandwidth) and the code for loading that data into the UDT which you then draw from, I would make a stab at using these transform API's. It would be very useful code to have in my repertoire.

ae_jester would have to supply that... I would imagine even a portion of the file for testing would be sufficient, otherwise you could use the sample line code in this thread.

I can't begin to fathom about how to code this...

Hmm

Interesting!

I've never even heard of 'world spaces'. One question, do these enable you to use other things such as circles, arcs and text? My drawing includes all of these.

Anyway, here is some sample data. (Size: 20Mb)

http://checkerscentral.hypermart.net/stCat6.zip

Here is simplified code to access the file and draw onto a picture box. Keep in mind this method takes about 30 seconds to load all the data before it actually starts drawing.

VB Code:

Private Function drawlinesX() As Boolean
    
    Dim mapLines() As mapLineType
    Dim fileNum As Long
    Dim strFile As String
    Dim numRecords As Long
    Dim i As Long
    
    fileNum = FreeFile
    strFile = "StCat6.dfl"
    
    'Open the data file
    Open strFile For Binary As #fileNum
    
    'Determine the # of lines to be drawn
    numRecords = LOF(fileNum) / Len(mapLine) - 1
    ReDim mapLines(numRecords)
    
    'Get the lines from the file
    Get #fileNum, 1, mapLines
    
    For i = 0 To numRecords
        With mapLines(i)
            'The way I've set the data file up, if the .lineType
            'property is equal to 1 then this means this is the 'header'
            'for a group of related lines.  This way the colour only
            'has to be set once rather than for every single line.  With
            'the world space idea this might not be the best way to do this
            If .LineType = 1 Then
                picMap.ForeColor = .Colour
            Else
                picMap.Line (.XPosStart, .YPosStart)-(.XPosEnd, .YPosEnd)
            End If
            
            'Keep track of the number of lines drawn
            curObjCount = curObjCount + 1
            
            'Refresh the map only every 10000 lines, to speed things up
            If curObjCount Mod 10000 = 0 Then
                'Update progress bar
                PB1.Value = Int(curObjCount / gObjectCount * 1000)
                picMap.Refresh
                DoEvents
            End If
        End With
    Next i
    
    picMap.Refresh
    
    Close #fileNum
    
End Function

VoloView Express, which is a light version of the full program created by VoloView, takes forever to load up initially, and in fact doesnt load up at all for very big files. But, if you manage to get a huge file loaded it takes seconds to zoom in/out or pan etc.

CableCad, generally regarded as the fastest CAD application takes approximately 20-30 seconds to load up the full map (the same map I am using) from it's own file format (who knows how they do it). But it takes less than a second to zoom into a region after this. Ultra fast! I understand cablecad makes use of a Quad File (as they call it) to speed the zoom process. I have no idea what this is or how it is done.

Quote:

---

One question, do these enable you to use other things such as circles, arcs and text? My drawing includes all of these.

---

From the example posted on the MSDN site, yes, they use ellipses(circles), lines and rectangles. So I imagine all drawing functions can be included.

From what I gather 'worldspace' is just like the entire drawing set a certain scale. You can then take any size region of that worldspace existing in memory, and zoom it, rotate it... etc...

http://msdn.microsoft.com/library/de...dspac_0jg3.asp

In order to run the code you gave, you need to tell us how you defined MapLineType....

I noticed you have .LineType property... so if you could post the decleration of the MapLineType....

VB Code:

Public Type mapLineType
    LineType As Byte
    XPosStart As Single
    YPosStart As Single
    XPosEnd As Single
    YPosEnd As Single
    Colour As Long
    Thickness As Single
End Type
 
Public mapLine as mapLineType

I can't get this to work with the file you linked to and the code you provided... so could you attach your entire project? I'm getting .xstarpos's in the 640000 range...

Ok, I got it to work, but I had to add these offsets; any idea why?

VB Code:

picMap.Line (.XPosStart - 632000, .YPosStart - 4772000)-(.XPosEnd - 632000, .YPosEnd - 4772000)

I guess I should have mentioned that the scale of the map is as follows

X Minimum: 634335.2
Y Minimum: 4772938
X Maximum: 648841.1
Y Maximum: 4789562

You can get around this problem with a picture box by scaling like this

VB Code:

picMap.Scale(634335.2, 4772938)-(648841.1,4789562)

I don't think I can post my entire project. My boss would kill me. There is a TON of confidential data in here :-)

I'll try and 'clean up' this form only and make a small project out of this and post this over the weekend.

Nevermind, that scale information is all I really need. I thought the data was corrupted or something funky had happened. I'll work on the worldtransform stuff within the next day or two...

Thanx a lot!

I really appreciate this. I just know there has to be a better way than the current method I'm using.

You know, using the code you post ae_jester, my machine can load and draw in less than 30 seconds... all you need to do is set Picturebox.Autoredraw=false, and remove the picturebox.refresh line....

As a temporary solution...

Yes but the image MUST be refreshed at least once in a while so the user can see what's going in (and also so they can stop the loading, and zoom in at a specific section). The load process takes about 2 minutes on the computer i use at work, its slow.

If you also consider there are similar files for arcs, circles, and text then you can see how this is a problem.

we might have a problem Victor, if we need to use SetWorldTransform, i'm not sure we do, but it appears SetWorldTransform is only available in NT 2000 , and not 95.98.ME

If you decide to not do DirectX or SetWorldTransform:
You might want to consider giving each line a priority level. 1 means it is always drawn, and n = only draw it if the priority level is this high. That way you can draw "rough" representations at the furthest zoomed-out level, which could take up to 1/n of the time it would take to draw every detail. Then, when you zoom in, you have to determine if a line will appear in the current window, and if not, don't even try drawing it (the IntersectRect api would be useful here).

Regardless of the above, you may want to convert the data in the dfx file to one of your own file format to compress it, without much (if any) loss in performance. The UDT you have to store the line information really only needs 9 bytes of storage, instead of the current 25.
Assuming:
LineType is a 1 or a 0 (1 or 2 currently) (1 bit)
X1 (XPosStart) is a single (2 bytes)
Y1 (YPosStart) is a single (2 bytes)
X2 (XPosEnd) is a single (2 bytes)
Y2 (YPosEnd) is a single (2 bytes)
Color (Colour) is from 0 to 15 (4 bits)
Thickness is from 0 to 7 (3 bits)

Thus, you have 4 coordinates of 2 bytes each, and bits totalling 1 byte. I.e., you can combine LineType, Color, and Thickness into one byte. You would use some bit manipulation and the CopyMemory API to get the data from the file into the array of linetypes.

I would think that this would at least halve the time it takes to load the data... and if not, then it probably would not take any longer than currently, and your datafile can be significantly reduced in size.

Question: do you need this to work on 9x, or just NT 3.1+?

I'm going to check out DirectX 8 and see if there is some way to tap into the hardware acceleration. Do the users of this program have systems that are designed for extreme CADD applications (4 million lines is extreme)? Special graphics cards?

What I've found so far is that the GDI (using the API or the form Line method) is the best way to go for 2-D stuff. However, that is only what I've looked for... I guess you'll either have to implement the above, deal with the slowness, or maybe try and find how industrial-strength CADD applications do their thing. However, I am not sure that there are CADD applications which will draw lines faster...

Victor, I had written the following directX code and posted it in the graphics forum... it was twice as slow as the API version, but some programmers told me this was because the VB wrapper function DrawLine was locking/unlocking the surface with each call, so now they told me to the LineTO on a DirectX surface, but still waiting for help on that one...

http://www.vbforums.com/showthread.p...hreadid=200945