Re: Solving the repaint problem?

Tech-Archive recommends: Repair Windows Errors & Optimize Windows Performance


"David Webber" <dave@xxxxxxxxxxxxxxxxxxxxxxxxxxx> wrote in
message news:%23eT7$%23q4HHA.5740@xxxxxxxxxxxxxxxxxxxxxxx

"Peter Olcott" <NoSpam@xxxxxxxxxxxxx> wrote in message
news:nx2yi.95509$6K3.77299@xxxxxxxxxxxxxxx

In Java programming the entire solution is summed up in a
single phrase: [double buffering].

Double buffering is a concept independent of "Java
programming" and of any other programming language.

This essential idea carries over to MFC.

It is independent of Java or MFC or for that matter
FORTRAN

If one does all of the slow operations in an offscreen
memory bitmap, then no matter how slow these operations
are, they can not cause any possible screen flicker
because they never directly touch the screen.

Yes.

The only remaining step in Java programming is to quickly
paint the screen with this offscreen bitmap at the
appropriate times.

Again the concept is completely independent of Java.

In MFC this would translate into a BitBlt operation.

It's a BitBlt operation in any language which uses the
Windows API.

The additional complexity of MFC programming is that the
framework does more than one explicitly tells it to do,
hence the need to over-ride the OnEraseBkgnd(CDC* pDC)
function.

The MFC framework provides default responses to
WM_ERASEBKGND and WM_PAINT messages. You are expected to
respond to both of those in any Windows program, whatever
language it is written in, and so I'm not sure what you
mean by MFC doing "more than one explicitly tells it to ".
It is part of the design of Windows.

You can respond to WM_PAINT using double buffering (or
not) in any language. The point of double buffering is
that it causes the drawing to wait for a moment while the
bitmap is constructed, and then produces the image on the
screen in a very short time as it is blitted. The
dynamics of the brain and the eye make this less
distracting than if the image is constructed gradually
over the same period in front of you.

So I'm not sure what the problem is.

It looks like the only problem is that I did not know that I
needed to over-ride the
OnEraseBkgnd(CDC* pDC) function, this is not required in
Java.


Dave
--
David Webber
Author of 'Mozart the Music Processor'
http://www.mozart.co.uk
For discussion/support see
http://www.mozart.co.uk/mzusers/mailinglist.htm



.

Relevant Pages

  • Re: using C# when adding new feature
    ... > We have MFC application from VC6. ... > cause less error beacuse it's an easier language. ... > with Java. ... a managed app - or at least a partially managed app), ...
    (microsoft.public.dotnet.languages.vc)
  • Re: Comparing Lisp conditions to Java Exceptions
    ... All the ISO standards in the world will not make the world ... Nothing keeps you from annotating your program with exceptions based on what ... language should adhere to your theory. ... Curiously, although you don't say it, Java has the opposite problem. ...
    (comp.lang.lisp)
  • Re: casts
    ... This is why most shit programmers refuse to learn languages including ... C Sharp and Java. ... compiler in a later edition of Visual Basic, ... language for processing data. ...
    (comp.lang.c)
  • Re: C, really portable?
    ... > Wait, is Java a modern language superior to C, or is it still ... It is a much better OO language than C++, ... It depends what you are doing, Java aims for rigorous portability - the same ... regardless of platform. ...
    (comp.lang.c)
  • Re: Is anybodys favorite computer programming language not included here?
    ... to talk about getting me some paying work writing Java classes. ... and could be copied to a script (as in Java BeanShell or Lisp PROG). ... >> please post a followup saying what language it is, ... Server: "Mother, ...
    (comp.programming)