Re: gtk_widget_draw()



On Sun, Aug 8, 2010 at 8:07 PM, Benjamin Otte <otte gnome org> wrote:
> Hi,
>
> Here's an email detailing my thought process for what I want to do
> with rendering in the master branch following the rendering-cleanup
> merge. It's mostly a brain dump, so treat it as such.
>
> I'll start with the end goal: gtk_widget_draw(GtkWidget *widget, cairo_t *cr);
> That function will draw the given widget to the given cairo_t, no
> matter what kind of cairo_t you hand it

I think I can subscribe to that. It sounds like a nice goal.


> 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 ?

> 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.


> So how do I get there:

[ Long list elided ]

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.

Matthias


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]