OpenEuphoria

Re: Needing some Windows programming help

• Posted by CChris <christian.cuvier at agriculture.gouv.fr> Jun 11, 2007
• 571 views

Dan Moyer wrote:
> 
> DB James wrote:
> > 
> > CChris wrote:
> > > 
> > > DB James wrote:
> > > > 
> > 
> > <SNIP>
> > 
> > > I'd take this problem the other way round:
> > > 1/ draw your graph on a memory bitmap (Pixmap in win32lib)
> > > 2/ handle the w32HPaint event fr your graph window and bitBlt() the
> > > relevant
> > > section of the
> > > graph.
> > > 3/ To improve smoothness, your bitmap should be wider than the window
> > > it will update, and, from time to time, just bitBlt() the "later" part
> > > onto
> > > the "earlier" part.
> > > 
> > > This is scrolling on a double buffered window.
> > > 
> > > CChris
> > 
> > Hi CChris,
> > 
> > Thanks for the ideas on how to handle this.  You gave me a lot to think
> > about.  I don't know yet how to "draw to a memory bitmap", but am not sure
> > that is the best way to go.  If I could do that, I wonder if I couldn't go
> > one better and write directly to the bitmap on the screen such that no
> > flicker would occur and there would be the sort of automatic refreshing we
> > expect in, for example, MS Paint.  There we could draw a square, fill it
> > with
> > color, and it would be refreshed no matter what obscuring happened to the
> > window it was in.  (Being cautious, I just tried it and of course it
> > worked.)
> > 
> > Unless someone else has a solution to suggest, I guess I'll read Petzold and
> > poke around with Euphorians' contributions related to bitmaps/pixmaps...
> > 
> > --Quark
> 
> DB,
> 
> I think the idea behind CChris' suggestion is that any write from Euphoria 
> directly to the screen will take a longer time to complete than the time
> it takes to bitBlt() the (finished) pixmap to the screen; therefore, while
> you're writing the data to the pixmap, although it takes some time, the
> screen stays the same, ergo, no flicker.  When your program is finished
> writing to the pixmap, then the subsequent bitBlt() happens sufficiently 
> quickly that *that action* shows no flicker.
> 
> Of course, I could be wrong :)
> 
> Dan Moyer

You are completely right. 

Flickering occurs when you paint repeatedly the same area. This is why a 
common technique to avoid flickering is to use a memory bitmap as a
scratchpad, and painting is a mere copy of that scratchpad onto the screen.
Plus, as indeed writing to screen is slower (you have to deal with monitor
frequency, retrace issues and all - it's a piece of hardware) than a plain
memory write, double buffering is good when you have many small patches to
update.
bitBlt() is very fast because, on modern machines, it takes advantage of
bulk memory transfers between the CPU cache and the video RAM. The drawing
GDI primitives are now comparatibely slow (this was not true at the time of
Petzold's book).

Another antiflicker is to prevent the window from erasing its background
(default behaviour) before any painting. repaintFG() in win32lib takes care
of this.

CChris