Re: gtk_widget_draw()

[Benjamin Otte <otte gnome org>]

On Mon, Aug 9, 2010 at 6:22 PM, Matthias Clasen
<matthias clasen gmail com> wrote:
>> 3) Resolution independence. A cairo_scale (cr, 2, 2) before calling
>> gtk_widget_draw() smoothly scales widgets to twice the size. Of
>> course, event translation and all that fun is needed, too, but the
>> rendering part is there.
>
> I fear that this glosses over considerable amounts of complication.
> How will input and output translation be kept
> in sync ?
>
No idea. I'm just hoping the new stuff makes it possible on the
rendering side of things. Then we "just" need to fix the rest of GDK
and GTK, and we're there!
In all seriousness, I have no idea what's missing for resolution
independence and suspect a lot. But there should be a lot less things
missing on the output side after I'm done.

>> 4) New backends. It's easy to render to anything that we can create a
>> cairo surface for. So integration with Clutter or other GL
>> applications becomes a lot easier.
>
> But...a backend still needs to have input handling and all that other
> fun stuff. I can that putting cairo surfaces between gdk and widgets
> will make widget implementations slightly nicer, and will make it easy
> to render a widget to anything. But gdk itself does not seem to
> benefit much from it, directly.
>
Of course. What you get is a free pass on writing the output side of
things - as Cairo can render anything using fallback as long as you
implement draw-to-window and -fetch-from-window. You'll still need to
code window handling, event handling etc. But from looking at the code
I already deleted in the rendering-cleanup branch, there's a few
thousand lines of code less to write per backend already.
You will not get backends for free yet - though you might get the
rendering for free. ;)

> Your list seems to largely consist of gdk refactoring. Which is not
> bad in itself. But a lot of the complication in the current gdk csw
> implementation comes from the replicating X semantics. So my question
> is: do you propose that we give up on doing this, with the argument
> that 'cairo is good enough' ? And if so, what are the semantics that
> we are replacing it with ? Having that spelled out clearly will no
> doubt be useful to future gdk backend authors.
>
Cairo and GdkWindow are orthogonal in a lot of places. In particular,
CSW have roughly nothing to do with Cairo. However, a lot of the
complexity inside the GdkWindow code comes from making pixmaps and
windows share a common base class and the impl/wrapper split. And now
that we separate windows from drawables, we can clean that up and
simplify the code and APIs. I think that's what most of my ideas aim
at. I don't think I want to change semantics. I don't even think I
know the code well enough (yet? ;)) to have definite ideas on how to
do that.

However, if we're already doing all this cleanup work, it might be a
good idea to rethink semantics. What I'm hoping is that with a cleaner
code base we'll find some very obvious cases where a slight change can
improve thhings a lot, and then we can fix those.

Benjamin