-
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
