Re: rendering-cleanup-next

[Havoc Pennington <hp pobox com>]

Hi,

On Sat, Sep 11, 2010 at 11:16 AM, Havoc Pennington <hp pobox com> wrote:
> I still think passing width, height to draw() is weird.

btw, I guess the argument here (per IRC) is that people might be
confused by allocation.x,y. But this is a really weak band-aid fix for
that, which will be wrong in the long term.

The solution to allocation x,y is to set the larger goal: widgets
don't know their transform (currently GTK only supports translation
transforms, of course). Widgets should always work in a self-relative
coordinate system, on the rare weird occasion where they don't, they
can use gtk_widget_translate_coordinates() which eventually could even
support rotation and scaling, or there could be a flavor that gives
you a matrix.

The actual bug is that widget_size_allocate() receives an x,y and
gtk_widget_get_allocation() gets an x,y. That's where the bug should
be fixed, not by adding some confusing stuff to draw().

It would take some thought to fix the leakage of x,y on the allocation
side, but I think that thought is what's needed, rather than band-aid
pseudo-solutions in draw().

Roughly, the solution could be that:

* size_allocate vfunc and wrapper change to (* size_allocate)
(GtkWidget, int w, int h)

* add gtk_widget_set_translation(widget,x,y)/get_translation()

* containers now have to call
gtk_widget_allocate_and_translate(widget, rectangle) convenience
function instead of size_allocate(). This convenience function
obviously calls size_allocate(rect.w, rect.h) and
set_translation(rect.x, rect.y)

This is a pretty breaking change, but porting apps is no harder than
changing expose-event to draw.

If you want to then be really sick and twisted, once you clear out
GdkWindow you can support a full cairo_matrix_t instead of just
translation... which would be logical and straightforward now that
you've kicked the translation out of the allocation.

Another possible solution is to keep the width,height to draw(), but
_get rid of size allocate_; widgets would then be supposed to support
any width,height at any time being passed to draw(), and they'd in
practice always have to cache their last layout for performance, most
likely. (they'd sort of make the first part of draw() do what they do
now in size_allocate(), iff the allocation has changed, and cache the
result). I don't think this is a very nice solution because it makes
draw() methods multi-purpose and clunky. I think it's cleaner to have
separate vfuncs for doing the layout and handling a paint on the
layout, as GTK already has.

Havoc