In article <005b01c7443a$57e42570$0301a8c0@Production>, "Paul" <pdeleeuw@deleeuw.com.au> writes:
Once I get CVS up and running and a copy of the source, I can look at some ideas that I have for updating the screen every second rather than every pixel.
It doesn't *quite* update to the screen every pixel. It accumulates a dirty region and redraws at most every time a key press is checked, but that's still a lot of drawing.
[...] There are a number of optimisations that can be performed if just working in RAM rather than to screen.
It works entirely in RAM right now. You *have* to do this in Windows because your window could get obscured and then exposed and you have to restore what was previously there. In other words, you can't depend on the "frame buffer" to remember what you drew to it -- so you have to have some sort of backing store. Right now this is an array of BYTEs and I redraw the screen from that with a StretchDIBits call. I could never get the rectangle blit working properly, so every time I draw its the whole screen, not the exposed portion. That would be a good change. There's lots more opportunities for speedy updates a la XaoS as well. XaoS is smart enough to reuse bits of your last computed image to compute the next image when you zoom in. However, it is still missing some major optimizations if you can believe that :-). This is part of why I want to separate the engine from the UI -- we need to get the engine computing on its own thread and once its separated we can also do some of the other display optimizations I want to try. -- "The Direct3D Graphics Pipeline" -- DirectX 9 draft available for download <http://www.xmission.com/~legalize/book/download/index.html> Legalize Adulthood! <http://blogs.xmission.com/legalize/>