Implement CompositorGL::SchedulePaint

Implement CompositorGL::SchedulePaint

BUG=None
TEST=views_desktop animations work on linux

[Ian Vollick, 2011-08-26 19:30:10]

Added an implementation of SchedulePaint. It unfortunately uses gtk/gdk; I've
added a TODO for the code's removal or ifdef'ing as we move away from gtk.

[sadrul, 2011-08-26 19:44:14]

LGTM

[jonathan.backer, 2011-08-26 20:22:27]

LGTM with nose-plugged.

I hate to see more GTK code. But I don't see anything in the X API that wouldn't
be a hack.

[sadrul, 2011-08-26 20:28:24]

On 2011/08/26 20:22:27, jonathan.backer wrote:
> LGTM with nose-plugged.
> 
> I hate to see more GTK code. But I don't see anything in the X API that
wouldn't
> be a hack.

I was going to suggest XSendEvent'ing an Expose event. But we can wait for
NativeWidgetX for that to happen.

[jonathan.backer, 2011-08-29 13:55:39]

On 2011/08/26 20:28:24, sadrul wrote:
> On 2011/08/26 20:22:27, jonathan.backer wrote:
> > LGTM with nose-plugged.
> > 
> > I hate to see more GTK code. But I don't see anything in the X API that
> wouldn't
> > be a hack.
> 
> I was going to suggest XSendEvent'ing an Expose event. But we can wait for
> NativeWidgetX for that to happen.

I wish there was a backend independent way of doing this (via Views). I don't
know enough about what's going on under the hood, but at this point (at least)
we're always triggering a fullscreen composite presumably via posting a task to
the message loop. So damage area is irrelevent and we should just be able to
post directly, no?

[vollick1, 2011-08-29 15:05:51]

May be could create a new interface in ui:: (something like ui::Paintable)
that widget inherits from and can be used for scheduling
compositing/painting. The compositor could hold a pointer to a ui::Paintable
and the various native widgets could provide their own, platform-specific
implementations of ui::Paintable.

On Mon, Aug 29, 2011 at 9:55 AM, <backer@chromium.org> wrote:

> On 2011/08/26 20:28:24, sadrul wrote:
>
>> On 2011/08/26 20:22:27, jonathan.backer wrote:
>> > LGTM with nose-plugged.
>> >
>> > I hate to see more GTK code. But I don't see anything in the X API that
>> wouldn't
>> > be a hack.
>>
>
>  I was going to suggest XSendEvent'ing an Expose event. But we can wait for
>> NativeWidgetX for that to happen.
>>
>
> I wish there was a backend independent way of doing this (via Views). I
> don't
> know enough about what's going on under the hood, but at this point (at
> least)
> we're always triggering a fullscreen composite presumably via posting a
> task to
> the message loop. So damage area is irrelevent and we should just be able
> to
> post directly, no?
>
>
>
http://codereview.chromium.**org/7766002/<http://codereview.chromium.org/7766...
>

[sadrul, 2011-08-29 15:23:47]

On 2011/08/29 15:05:51, vollick_google.com wrote:
> May be could create a new interface in ui:: (something like ui::Paintable)
> that widget inherits from and can be used for scheduling
> compositing/painting. The compositor could hold a pointer to a ui::Paintable
> and the various native widgets could provide their own, platform-specific
> implementations of ui::Paintable.

Since ui:: cannot depend on views::, ui::Paintable sounds like a good plan.

From a quick search, it looks like 'Compositor::SchedulePaint' is only called
from ui::LayerAnimator? If so, perhaps the LayerAnimator could hold a pointer to
ui::Paintable and do SchedulePaint instead of going through the compositor?

[Ian Vollick, 2011-08-31 20:23:31]

On 2011/08/29 15:23:47, sadrul wrote:
> On 2011/08/29 15:05:51, http://vollick_google.com wrote:
> > May be could create a new interface in ui:: (something like ui::Paintable)
> > that widget inherits from and can be used for scheduling
> > compositing/painting. The compositor could hold a pointer to a ui::Paintable
> > and the various native widgets could provide their own, platform-specific
> > implementations of ui::Paintable.
> 
> Since ui:: cannot depend on views::, ui::Paintable sounds like a good plan.
> 
> From a quick search, it looks like 'Compositor::SchedulePaint' is only called
> from ui::LayerAnimator? If so, perhaps the LayerAnimator could hold a pointer
to
> ui::Paintable and do SchedulePaint instead of going through the compositor?

That could work. I'll be adding another class that will want to schedule a
composite, but this class could certainly hold a pointer to a widget or a
ui::Paintable for this purpose.

[sadrul, 2011-09-02 17:02:09]

Let's send this as it is to sky@, and try to land. And do the better fix at a
later time?