I have to make a VB application without using DirectX, and graphics speed is crucial. While searching through MSDN I have learned that VB provides a PaintPicture method for forms. I was planning to use the API function BitBlt which i suspect PaintPicture eventually winds up using anyway. Now, if I use BitBlt, I have a second problem. Stuff doesn''t want to stay on the form unless I turned on AutoRedraw, which I have read causes the entire form to be redrawn each time its changed. With the way my application is structured, AutoRedraw may be faster than using the Paint event of the form IF it keeps being generated everytime the form is changed (shouldnt it only happen when form graphic data has been lost? not when i change the form through bitblt?). I have a feeling that because ofthis, the form is being redrawn twice, once by me, once by VB, but if i turn off AutoRedraw, stuff just doesn''t "stick". I have also noticed that i must call Form.Refresh before anything i draw to the form''s HDC gets shown. What im asking for is any help with speeding up VB graphics, and how to draw on the form with as much speed as possible. Every lost drop of speed i need, every CPU cycle. Any suggestions are welcome and hugely appreciated!

You could turn off autoupdate when you make the changes and turn it back on. I don''t have any real experience with VB so this is just guessing. Another is to look for a beginupdate, endupdate pair so that you can make a bunch of changes then update the screen with the result when you do the endupdate. I''m somewhat suprised that PaintPicture retains the image at all. I would expect it to be drawing straight to the window dc due to the paint part of the name. If it is retaining then it is retained in a bitmap which is being blitted to the screen on refresh. That is why when you draw you don''t see it until refresh. You drew on the bitmap, but it hasn''t been blitted to the screen. So once you update the bitmap call refresh or paint to update the screen. If the AutoRedraw is on PaintPicture then it is most likely controlling whether you draw straight to the window dc or to a bitmap dc. If that is the case then without it you have to write a paint routine to repaint sections of the window which means remembering everything that was there.

This is definately a most interesting topic... Can someone explain to me more about how Windows handles drawing to DC''s, nad when it actually draws to the screen? I''m writing a text-editor app that uses DrawText many times (and draws fairly fast), so I know some things about squeezing speed out of VB... but is there a way to tell it not to actually update the screen data until I''m done drawing? Some way I could eliminate the flicker I''m getting right now? I''d appreciate it...

LordElectro, I may be able to help you if you could tell me a bit more about what you need to do...


Random tip: if you''re going to do a lot of string manipulation when loading a text file, it''s actually REMARKABLY faster to load the file as a binary array, do the manipulation, then convert it (character-by-character) to a string.

--Tr][aD--

Here i go again

i answered this in another thread

windows redraws on WM_paint megssage

so if u want to get rid of flicker just use a doulble buffer scheme: make 2 memory DC''s with a bitmap large selected into them
paint to one of them,(the "backbuffer") and at the end of paint just Bitblt the whole buffer onto the "primary buffer" and on wm_paint bitblt the "primary" one onto the windows DC (get this one by BeginPaint /EndPaint sequence only inside the wm_paint handler)

That will eliminate any flicker

As for VB...hmm.... speed is not the strong part of VB...maybe try to use some direct winapi call...maybe so u will get some speed (DirectX is better IMHO)

Bogdan

Well if I was doing this for my own enjoyment and education, you wouldn''t catch me dead using VB or Windows graphic routines. C++/DirectX is how i communicate with the system (though i miss direct hardware access that u got in DOS)

Sadly though Im stuck with this stuff, and it aint making me happy. I figured out my own problem, or at least got it good enough so I SHOULD be able to accomplish what I am attempting. I wish everyone used Win2K, it has much better GDI, takes advantage of hardware acceleration, HUGE speed difference, as i found out the hard way.

Im afraid bogdanontanu''s technique wont work. It is essentially what what the autoredraw property does anway, and doing a bitblt of an entire screen using that awfully slow bitblt function is pure evil. In DirectX, the blting function are fast enough for such a thing (although it is far better to just setup a double buffer surface and let it work it''s memory switching magic, so no blt has to be performed)

Oh, in case anyone is wonder, here is what i came up with
Set Autoredraw to False
Draw graphics whenever u need to
In the Form''s OnPaint event, redraw entire screen

Calling Form.Refresh will call the OnPaint event btw, as well as user swtiching window focus and the usual stuff like that.

WinAPI functions... yes... WinAPI functions are goooood.... (''s what I use)

That''s pretty much what I do, but how ''bout a way to do it with less flicker?

btw: bogdanontanu... VB has no WM_PAINT event... in fact, it has no event handlers like that, PERIOD. It has what''s more-or-less a CALLBACK function called Form_Paint, which gets called instead.

And you''ll have to explain to us how to create this second DC in VB.

--Tr][aD--

Usually it is the erase background that causes the flicker. How you get rid of it in VB I don''t know. When you really don''t need it there is a problem. If you blanking the background in the paint routine then you actually need it so use it. Set the background to the color you want it and don''t blank it in your paint routine. When you are simply blitting a bitmap to the screen is where it is really a problem because before you blit it was filled with the background color. Basically it took you twice as long as it should have. I also make a practice of just blitting the section within the clip rectangle. I haven''t tested to see if it makes any real differance, but I try not to count on Windows not doing anything stupid like checking each pixel to be moved to see if it is within the clipping rectangle instead of adjusting the source rectangle once. Software gets better and processors get faster, but old habits die hard.

The easiest way to tell which type of dc you are drawing against is to draw to it outside the paint event. If you minimize and restore the window and it is still there then it was a bitmap dc. If it is gone then you were drawing to the screen.

Ok, I went and looked a bit of VB doc. Eek, glad it isn''t me. Anyway try setting the forms fill style to transparent. You may have to play a bit with just exactly what you do that to.