refreshing

Take a look at the approach in RefreshingDisplayPolicy (see class side
methods for examples). It uses a bitmap snapshot of the parent to
process damage events until the long block finishes, so the parent
_application_ doesn't have to tolerate damage events, but the parent
window doesn't get "greyed out" if it is obscured and revealed (e.g. by
moving the child).

Absolutely: that's what will happen normally, but not if you use
#drainOutstandingEventsFor: (as you know). I didn't mean process the
damage events right away, just not to drain them.

Are you sure the user is able to get two identical keypress events in
the queue before your app starts to process the first? I can't press a
key twice faster than 70ms, which would give VW huge amounts of time. Is
it that VW really is that slow to react, or is it under heavy load or
something?
 
Steve

Steve,

On 17/02/06, Steven Kelly <[hidden email]> wrote:

> > In the latter case, we just have to put up with accumulating
> > damage until the child closes, where upon I do a >>refresh to
> > completely restore the parent.

> Take a look at the approach in RefreshingDisplayPolicy (see class side
> methods for examples). It uses a bitmap snapshot of the parent to
> process damage events until the long block finishes, so the parent
> _application_ doesn't have to tolerate damage events, but the parent
> window doesn't get "greyed out" if it is obscured and revealed (e.g. by
> moving the child).

You know, what I'd like to do in this particular case of ours is
*explicitly* grey out the whole window.  This is because, from a
business POV, the old information on the screen is out of date and
potentially misleading from the moment the child opens (this is why a
repair fails - the presented information is in a state of flux).  So,
in this particular case of ours, grabbing a bitmap of the last good
state of the parent  would not be appropriate.

I can see that  it would be hugely useful to hold a bitmap-snapshot on
a window in other cases.  I hope this makes it into the base.

> > I don't understand why we would wish to process the damage
> > events for all windows in the WindowManager explicitly.  It
> > they are left in the EventQueue, surely they will be
> > processed in the natural course of things anyway.
>
> Absolutely: that's what will happen normally, but not if you use
> #drainOutstandingEventsFor: (as you know). I didn't mean process the
> damage events right away, just not to drain them.

I understood that >>drainOutstandingEvents was specific to an
ApplicationWindow, and if this is the case (it looks like it is) this
is just what we need.

We are using the drain events with respect to one window (the parent)
for which the programmer has explicitly said they want events to be
ignored.  All other windows in the WindowManager  are not affected,
which for us is a good thing.  Perhaps I'm missing your point here -
sorry.

> Are you sure the user is able to get two identical keypress events in
> the queue before your app starts to process the first? I can't press a
> key twice faster than 70ms, which would give VW huge amounts of time. Is
> it that VW really is that slow to react, or is it under heavy load or
> something?

Oh, yes, we are sure :-)

The thing is that the (normally small) time window has been made much
wider because IO is performed *after* the first event is received but
*before* the dialog is opened.  In the specific case, <alt>+s is a
request to open a dialog.  <alt>+s is handled by a method which looks
a bit like:

altSMethod
  subjectBuisinessObject := self doLotsOfSlowIO.
  (MyDialog on: subjectBusinessObject) openAsDialog.
^self

So, while >>doLotsOfSlowIO is running the user can sneak in other
input events (mouse and keyboard events), for example another <alt>+s
or three.

The fixed method looks like this:

altSMethod
  self mainWindow doWhileHandlingOnlyDamageEvents: [
   subjectBuisinessObject := self doLotsOfSlowIO.
   (MyDialog on: subjectBusinessObject) openAsDialog].
  ^self

In this case, the >> doWhileHandlingOnlyDamageEvents: *imediately*
starts blocking the unwanted events.  >>doWhileIgnoringAllEvents: is
the same but would ignore even damage events, but we only need this in
one case (as discussed above) at the moment.

So, the time window in which stray events can get in is much smaller
now.  Sufficiently small that we don't see the double-event problem
any more.

All the best,
    Bruce
--
Make the most of your skills - with OpenSkills
http://www.openskills.org/

> We are using the drain events with respect to one window (the
> parent) for which the programmer has explicitly said they
> want events to be ignored.  All other windows in the
> WindowManager  are not affected, which for us is a good
> thing.  Perhaps I'm missing your point here - sorry.

I imagine it's me getting the wrong end of the stick - usually is! Let's
not worry: we both know you want to throw away input events, but have
the damage events processed eventually. #drain... will do the first, but
not the second. That's all I meant. Given you want the window all grey
anyway, and will send an explicit refresh for the whole window at the
end of altSMethod, losing damage events doesn't matter in your case.

OK, so actually not exactly what I meant: your app _starts_ to process
the first event before the second one is in the queue. That's what gives
you the chance to get in there straight away with code that stops
further input events being added. In other words, when your new
altSMethod starts to run, it's unlikely there will be any extra input
events already in the queue. Thus when the second alt-S comes, your new
#addEvent: will already filter it out - so you probably don't much need
the code to drain events at the start of altS.

Of course, there's always the chance someone's finger will slip from S
to D, so you get an alt-D in the queue right after the alt-S, and before
your altSMethod gets a chance to get started. Figuring out whether that
is possible might take rather a lot of analysis of how exactly your
keyboard, its driver, Windows, the VM, and VW process the events and in
what kinds of processes. Even though the user presses alt-D before your
altSMethod starts, it's possible it hasn't made it to the WindowManager
event queue yet.

Cheers,
Steve

Sames,

sorry to keep you waiting: it was a week before I had the spare couple
of hours I needed to refactor out the references to our own stuff. The
result is now published as version 2.2 of RefreshingDisplayPolicy in the
public Store.

The package has two approaches, as I mentioned here earlier:

RefreshingDisplayPolicy usePixmapWhile: ["long block"]
tries to make VW accept refresh events but not input events. There seem
to be just too many holes in Wrapper for this to ever be perfect, but
the current version is pretty close to acceptable production quality

RefreshingDisplayPolicy progressWhile: ["long block"]
opens a progress dialog (with gauge and transcript) during the long
operation. Because Windows' modal dialog behavior handles refreshes but
not input events, some of the heat is taken off VW, and the results are
closer to perfection.

You can try it out with "RefreshingDisplayPolicy example1" - although be
warned that because the example window is a text editor, all the horrors
of Wrapper writing directly to the screen rather than invalidating areas
will be apparent. It also looks like something has changed in the VW
double buffering that usePixmapWhile: uses, since it appears to buffer
an old version of the window contents(shouldn't be hard to correct).

It's a bit late now, so I ought to stop - hopefully the documentation in
the package and class, plus the earlier discussion here, are enough to
let you get started looking at this. Feel free to send me questions if
things aren't clear.

All the best, and thanks for taking a look at this issue,
Steve

> It looks like something has changed in the VW double
> buffering that usePixmapWhile: uses, since it appears to
> buffer an old version of the window contents(shouldn't be
> hard to correct).

Now corrected and published as 2.3. The problem hadn't shown up for us,
since we use a transparent dialog (TransparentWindows package). Without
the correction the whole thing basically didn't work :-(.

> It's a bit late now, so I ought to stop
... or maybe not publish until I'd sorted the bug out? Sorry!

Steve