Re: MrEd event handling

[Matthew Flatt <mflatt@cs.utah.edu>]

At Wed, 24 Apr 2002 18:38:35 +0000, thomas.witzel@attbi.com wrote:
> When I create a window and then resize it slowly or just
> resize it madly alot of times my program gets bombed with
> a long train of on-paint events for a while. 

Unix+X, I presume?

> I would like
> to process always just the newest event in the queue and
> discard/dispatch all other on-paint events that are
> waiting the queue.

It's a shame that the X event dispatcher doesn't already do this for
applications.

I suppose MrEd could peek ahead in the event queue and collapse update
events itself. It doesn't sound difficult, but I'm not sure.

Fixing the resize problem is likely more difficult. You get into
trouble with the asynchornous nature of X events and the size-update
model of the underlying Xt widgets. But, now that you pair the resizing
issue with the update issue, I wonder whether there's a simple
event-queue lookahead strategy that could fix the resize problem, too.

> Also if I get an on-paint event it would be nice to find
> out which region of my canvas has been damaged and needs
> to be repainted.
> Is there any functionality that does what I want to do or
> somebody working on that problem ?

No. In principle, it wouldn't be too difficult to add an operatio that
gets the bounding box of the current update region.

I have to say, though, that I've never found such an operation to be
useful. It's often worthwhile to limit drawing to the current visible
region, but I've never seen fine-grained masking pay off.

> I would like to volunteer otherwise but I'am quite new to
> mzscheme/MrEd so it would take me a while of reading and
> understanding the code before my doing would not be life
> threatening for the compiler ;-)

If you want to try to implement update-event collapsing (or try to fix
the resize problem via lookahead), plt/src/mred/mredx.cxx is the place
to do it.

Matthew