CLIM mail archive

[Prev][Next][Index][Thread]

Re: [spr5329] X-Window interaction with CLIM




> I have been playing around with my CLIM application and found some interesting
> quirks in its operation.  My application has extensive graphics and text on
> the screen.  I have noticed that if I successively close the application down
> into an icon and reopen it (without giving the display a chance to fully
> update itself - also during the course of a gc) that when I open the
> application icon and give it time, the application sort of redisplays itself
> the number of times that I had successively opened and closed the icon before
> even though it isn't necessary.  NOTE: My application uses my own history
> mechanism and doesn't use any of CLIM's incremental type features
> (ie: updating-output and such)!

This is a hard-to-avoid consequence of the way X11 Exposure events work.
Each deiconification of the CLIM window generates some number of Expose
events.  CLIM is a "smart" window system, so rather than simply waiting for
the "last" Expose event (the one with a 'count' of 0), it goes ahead and
repaints whatever region each Expose event describes.

This is highly optimal in many cases, say when the user is dragging a
smaller window over the CLIM window.  It is also "optimal" in the case of
de-iconification, since it redraws the whole window once, which is the
same thing a dumb application would do.

What would be nice is if there was a simple way of looking forward in
the event queue, seeing if there are Expose events further ahead in
time that "contain" (in the geometric sense) the Expose events you're
currently processing.  If so, ignore the current events.

This approach is difficult implementationally, mostly for reasons that are
too complicated to explain via email.  I'll file an RFE anyway, so we
consider the issues involved.

Fortunately, the situation will be ameiliorated in CLIM 2.0, as the
contents of the application frame are kept in the server's backing store.
On most X servers (like Suns) this reduces the problem to near zero.  (I'm
speaking of our version of CLIM 2.0, I don't know what the other vendors'
plans are).

C applications have the same problem, although they don't usually have to
fault in as many pages to repaint the window.

> Also, I am running Composer.  When the debugger window comes up and I
> bring up additional inspector windows and flush them or I do restarts in
> the debugger resulting in successive appearance of the debugger window (ie:
> in a loop or such) the application display refills the same display area that
> the debugger/inspector windows came up in over and over again the same number
> of times (even if the display area was the same).

Um, I'm not sure exactly what you're describing.  If you are saying that
CLIM tries to repaint the application frame each time the X server tells
CLIM that the frame's contents are no longer valid, you're right -- this is
the same problem detailed above.  If that's not what you mean, perhaps you
could restate your example?

	-- John



Main Index | Thread Index