Re: Size allocation and redrawing issues

[Owen Taylor <otaylor redhat com>]

Soeren Sandmann <sandmann daimi au dk> writes:

> Owen Taylor <otaylor redhat com> writes:
> 
> >  - gtk_widget_set_redraw_on_alloc() is added as in my original
> >    mail for widgets that want to handle redrawing on resize
> >    themself.
> 
> If a NO_WINDOW widget is moved, the union of its old and new
> allocations is invalidated, whether the widget is REDRAW_ON_ALLOCATE
> or not.
> 
> I don't think this invalidation should be done automatically for
> widgets that are both NO_WINDOW and !REDRAW_ON_ALLOCATE, because of
> the many NO_WINDOW containers that don't actually draw anything (hbox,
> vbox, hbbox, table, etc). Also, NO_WINDOW widgets such as GtkFrame
> that don't draw much can just invalidate two pretty small areas in
> their size_allocate implementation.

OK, I've gone ahead and done this, and also made GtkBox, GtkFrame,
GtkAlignment take advantage of this. We can't do this kind of change
later as an optimization, asI say in Changes-2.0.txt

* The GtkBox, GtkTable, and GtkAlignment widgets now call
  gtk_widget_set_redraw_on_allocate (widget, FALSE); on themselves.
  If you want to actually draw contents in a widget derived from
  one of these widgets, you'll probably want to change this
  in your init() function.

Drawing speed is not really that proportional to the number of pixels
drawn in most cases, so trying to optimize GtkFrame to only redraw
little areas sounds like a lot of complexity for not so big again.
 
> >  - Invalidation when a widget is resized or moved is "shallow" as 
> >    described above - only the windows that need to be invalidated
> >    are invalidated.
> 
> There are still some calls to queue_clear that invalidates
> _everything_ on opaque resize, including one in
> gtk_widget_queue_resize, so your patch doesn't actually reduce the
> amount of redrawing. It is easy to remove this invalidation, though.

I've fixed some places in my commit for reduced invalidation on
opaque resize.

 - make queue_resize() invalidate shallowly, not deeply.
 - make gtk_window_configure_event() call _gtk_container_queue_resize()
   since we don't need the invalidation at all for this case.
   (I'm not sure this helps - it might actually speed things up
   to have a solid region for the window's background when we
   start invalidating subregions)
 - Remove a call to gdk_window_queue_redraw() in gtk_window_move_Resize()
 - Make gtk_frame_size_allocate() call gdk_window_invalidate_rect()  
   rather than gtk_widget_queue_clear().
    
> Also, I think some operations on GdkWindows could and should
> invalidate more than they do currently. Moving or resizing a window
> should at a minimum invalidate the uncovered area in their
> parents. This would maybe avoid some waiting for expose events.

If you want to look into this, go ahead. Probably good to stop short
of dealing with overlapping sibling windows though ... they don't
occur very much in widget layouts and gets significantly more
complicated once you have to start worrying about stacking order...

                                        Owen