#47 Invalidated areas not updated

[Bryan Wagstaff]

This is a complex issue, but it needs to be addressed.

On a related note, SCREEN::pause() and SCREEN::resume
() don't seem to be implemented.

(Windows OpenGL shim specific)

The renderer should cause the screen to be updated
when a portion of the screen has been invalidated by
the OS.

If the screen is covered and uncovered, one of several
things should occur:

1 - rendering should occur, effectively updating the
screen. There may be performance problems if
invalidations occur while rendering is active, or
animation problems if the rendering causes data to
change.

OR

2 - screens should keep a memory of their content
after every update, and use it for refreshing.
Obviously the performance impact for doing this is too
great.

OR

3 - screens should indicate if they are actively
updating themselves or not, and the system should
decided #1 or #2. (like pause() and resume() would
do). Unfortunately this requires the programmer to
actually do something, which is a bad assumption.

(A similar problem is the assumption that the
programmer will actually turn on the mouse wait cursor
when doing any processing or blocking function. We
can't do it around all functions because the mouse
will flicker between ready and wait all the time, but
we don't know in advance how long most processing will
be or how long a blocking function will take.)

OR (my personal favorite)

4 - If the screen is invalidated and pause() has been
called, an image of the screen is plastered up. If
pause() has not been called, rendering should occur.
The side effect is that Windows tends to generate a
few hundred invalidation messages when one window is
dragged over another. In that case, messages should be
queued and dropped similar to mouse message queue
droppings (if update in progress, ignore message).

-----------
- Example -
-----------

My render function performs a check to see if it is
supposed to be running. If it is not, a message will
be shown on the screen (indicating no connection, or
the status). This rendering is only performed when
the state changes, not in a typical rendering loop.

Based on what I read, SCREEN::pause() and
SCREEN::resume() are supposed to do this, but they are
not implemented. I would imagine that I would call
SCREEN::resume(), update the screen, then call
SCREEN::pause() after showing the status change.

I presume that calling pause() would grab an image of
the display from the framebuffer and redraw that image
when the display is invalidated.

After the app is running, another window is dragged
over my viewport. I should have extra SCREEN::update
() calls. Since I perform animation and rendering in
separate threads, and because I share a critical
section between animation and rendering, extra
rendering will not interfere with animation, other
than possibly causing it to wait for a frame to finish.

If I performed my animation within the update()
function, this would not work.

Bryanw