Re: [gtk-list] Re: GraphicsExpose (was Re: About the About Box)

[Raph Levien <raph acm org>]

On Wed, 17 Dec 1997, Owen Taylor wrote:

> Unfortunately, it turns out not to completely correct - the killer
> case is that a regular Expose event can occur but not be processed
> when we do a XCopyArea. In that case there are regions that X thinks
> are correct, but which aren't.

Yeah, I thought of this case this afternoon while walking around. It 
seems a bit unlikely to happen in real life, so I think leaving things as 
they are for 1.0 is ok.

This does make me uncomfortable, though. I'm a big believer in real 
correctness.

On another point, you talked about checking for overalapping Expose events
(mostly in the context of translated GraphicsExpose events). I think an 
important goal for post-1.0 Gtk is to optimize Expose handling in 
general. Certainly, the case of an opaque move over an "expensive" Gtk 
window is not very well handled now.

I've done some work on this for Gzw, and will briefly describe what I'm 
doing here.

All repaints, whether due to X Expose events or to invalidations by the 
application, get added to a repaint_region for the scrolling area. The 
repaint_region is a GzwRegion data structure, which can represent regions 
of arbitrary complexity, but is optimized for rectangles. The code is 
lifted straight out of xink/gsumi.

Whenever the repaint_region is non-empty, an idle process is started, 
which takes a rectangle out of the repaint_region and repaints it. 
Currently, the tiling of the repaint_region is exact. In other words, it 
optimizes for the total number of pixels painted, which will be at the 
expense of the total number of rectangles, especially if the region 
becomes complex. Thus, the long term plan is to do an approximate tiling 
of the repaint_region, to get many fewer rectangles. The API for this 
currently exists, but not the code.

I haven't done the approximate tiling, but even without it performance is 
pretty good. I'm basically happy with this approach. I believe it has 
significant advantages over Gtk's object-based repainting queue, namely:

1. Widgets can ask for parts of themselves to be redrawn with arbitrarily 
fine granularity. It's worth noting that Gtk already has specialized 
painting methods for dealing with certain special cases (focus and 
default). My feeling is that these specialized methods can be subsumed 
into the single, unified request_repaint API of Gzw.

2. The repaint_region is pruned to the visible area of the scrollable 
region, saving lots of work if widgets change state invisibly.

3. The opportunity for optimization, as discussed above.

4. Incremental repaint and resize works. Specifically, one widget in a
container can change size without having to redraw the whole thing - not
currently possible (at least in NO_WINDOW mode) in Gtk. 

Thus, my conclusion is that region-based expose handling would be a win 
for Gtk 2.0. I believe the incompatibility costs are minimal and the 
benefits substantial.

If we are going to rework the expose handling, then I think that's a good 
time to reopen the issue of the best way to handle these scrolling 
problems in a way that's completely correct in all cases, and also an 
efficient use of the X protocol. I'm not married to either the 
synchronous or the asynchronous approaches - it should be possible to 
choose the one that works best in practice.

Raph