OpenEuphoria

Re: Needing some Windows programming help

• Posted by DB James <larches at comcast.net> Jun 11, 2007
• 608 views

CChris wrote:
> 
> 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

Thanks to CChris and Dan and Pete for the helpful comment.

I have done some experimenting and find that CChris' original comments were
right on -- I just hadn't any idea how to do it yet!

But I wrote a little test program that worked like magic.  Using a Bitmap,
an Icon, and a PushButton, I was able to generate pixmaps for all three and,
by putting an update function call in the onPaint event programming area of
each object (using Judith's IDE), the pixmap data is refreshed neatly when
need be.  Now to transfer the knowledge to L and D...

CChris' idea of having a wider Pixmap, I doubt will be necessary, but it does
raise interesting notions of little GIF-like "movies" dancing around on
objects 


--Quark