Re: rendering-cleanup worries

[Alexander Larsson <alexl redhat com>]

On Mon, 2010-08-23 at 10:07 +0000, Benjamin Otte wrote:
> Alexander Larsson <alexl <at> redhat.com> writes:
> > It may seem correct and easier, and in most cases it will work. But
> > things like that were added for a reason. In this case it is to make
> > things like notification icon work, where there the parent of the window
> > we paint in is a foreign window (the tray) so we don't know what
> > background it has set. Using a native X clear function means we'll get
> > this right anyway. Without this change all systray icons get a black
> > background.
> > 
> Looks like I'll have to fix gtkstatusicon.c to call XClearArea.

Yeah, for a non-container widget like statusicon something like that its
probably enough.

I don't mean that this particular problem is impossible to solve, just
using it as an example of the little details that will haunt you as you
try to use any new larger redesign.

> > In general I'm a bit worried about the rendering cleanup branch wrt
> > non-obvious issues like this. After doing the "simple" part of the csw
> > work I spent many months chasing minute issues like this to make the
> > full desktop with all its apps work with csw. 
> >
> I don't think it's GTK's job to have corner-case workarounds for weird
> platform issues. If that were the case, we could just get rid of GDK and
> use libX11 directly. To me GDK is supposed to be a useful abstraction to
> write a portable widget toolkit, so I'm not too worried about not handling
> corner cases as long as we allow apps to handle them on the libX11 level
> should they care.

I don't think its gdks job to handle the corner cases, however it is the
interface to the lower layers that *lets* you solve the. It is the
interface between the libX11 level and the gtk level, and as such it is
inherently shaped by how the underlying implementation works.

> > I fear that we will not be
> > able to do this with gtk3, because there are not enough apps to expose
> > all the corner case issues we might hit before we release, and by then
> > we're frozen and may be unable to fix some issue.
> > 
> This won't happen unless we get some more developers spending time on this
> stuff. And so far I'd say there's just me - and a large group of
> enthusiastic but worried bystanders.
> 
> Still, GTK3 is an API and ABI break, so we can allow semantic changes. If
> we intend to keep GTK3 rendering 1:1 compatible with GTK2, then I should
> probably stop doing this work, because it definitely is intrusive enough
> to break things, in particular for apps that rely on weird corner cases
> (like Mozilla or Eclipse). This is not intended to be like your csw work
> where you were trying to guarantee binary compatibility. In fact, one of
> my goals is the direct opposite: I want to make the code easier. And I'm
> happy to sacrifice lots of corner cases for this.

I don't particularly care if we "break" mozilla or eclipse as they exist
now. I mean, we already do that just by breaking the abi. Its more that
I fear that the needs of something more complex like a full desktop with
panels, systrays, desktops, browser plugins, document object embedding,
etc. at times do require "weird" stuff in the lower layers to make it
work. And there is a risk that not allowing "weird" stuff will cause
problems down the line.

Anyway...

I don't want to seem like a backwards person. I very much agree that by
breaking a few eggs Gtk3 could be a much better omelet. I think I
understand where you're going with your reasoning, but I think you're
slightly off. If I were to do a larger change of the underlying gtk+
system like you're proposing I would do it a bit differently:

1) Kill all the csw rendering and event propagation from GdkWindow. 

        Make a GdkWindow simple and one-to-one with a native window. In
        your typical app  there will only be one such for each window,
        but in "weird" situations (like Xembed and such) it would let
        you create subwindow that have a reference in the gtk+ world so
        that the internals know about their existance and status and can
        do the right things. Also, we could probably simplify the window
        operations a bit as many things might not be needed anymore.
        This way Gdk is again just a porting layer for the non-drawing
        part of the windowing system. 

2) Remove GtkWidget->window. 

        All windows just render in the cairo_t they get to draw in, and 
        such rendering is clipped by the painting algorithm traversing
        the widget hierarchy, unrelated to any windows. Scrolling and
        suchlike is implemented by widget clipping and
        offsets/transforms (although we would need to make sure there
        are special casing for axis-aligned rect scrolling so we don't
        always repaint everything when scrolling).
        
3) Change the event model

        GdkWindow still deliver "native style" events to the toplevel,
        but this is converted by GtkWindow or suchlike to a DOM style
        capture (go down) then bubble (go up) model. This event handling
        would be done by the widgets, and as such wouldn't look exactly
        like the current one (no masks, widgets can control how events
        look like to the lower hierarchy, etc).

A model like this makes it *much* easier to handle the kind of things
you want, like pure cairo rendering, transformations, draw-over-parent,
etc. It also likely makes making new widgets easier and natural.

However, it would also make porting existing widgets a major endeavor.
You need to basically redo the whole event and repainting system for the
more complex widgets like the treeview and textview. It definitely will
not be the almost-trivial kind of porting changes you've talked about
before, with the expose to draw() conversion. Although for a typical app
that just uses widgets it might not be that much of a change.

I would love having Gtk3 be like this. But then we're talking a
completely different level of change. 

-- 
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
 Alexander Larsson                                            Red Hat, Inc 
       alexl redhat com            alexander larsson gmail com 
He's a globe-trotting sweet-toothed sorceror in a wheelchair. She's a 
manipulative streetsmart cab driver with a birthmark shaped like Liberty's 
torch. They fight crime!