Compositor thread plumbing for layout rectangle debug info.

Plumbing for layout rectangle debug info. Companion to

https://code.google.com/p/chromium/issues/detail?id=314945

Patch from Chris Harrelson <[email protected]>;

BUG=314945
..


..


Plumbing for for layout rectangle debug information.

BUG=

Committed: https://src.chromium.org/viewvc/chrome?view=rev&revision=238297

[chrishtr_gmail.com, 2013-11-06 20:52:50]

One issue with this CL: not clear to me yet the best way to pass the debug info
interface across the boundary from blink to compositor. Right now I had to
bypass the presubmit check to avoid it complaining about the #include of a file
in third_party/WebKit/platform/public/

[chrishtr_gmail.com, 2013-11-16 05:17:55]

This CL is now in final form and ready for full review.

[nduca, 2013-11-25 18:24:34]

lgtm

[enne (OOO), 2013-11-25 20:16:44]

https://codereview.chromium.org/61883006/diff/220001/cc/layers/layer.cc
File cc/layers/layer.cc (right):

https://codereview.chromium.org/61883006/diff/220001/cc/layers/layer.cc#newco...
cc/layers/layer.cc:933: layer->SetDebugInfo(debug_info_);
ConvertableToTraceFormat is not thread-safe refcounted.  This seems a little
dodgy.

https://codereview.chromium.org/61883006/diff/220001/cc/layers/layer.h
File cc/layers/layer.h (right):

https://codereview.chromium.org/61883006/diff/220001/cc/layers/layer.h#newcod...
cc/layers/layer.h:442: virtual void
SetDebugInfo(base::debug::ConvertableToTraceFormat*);
style nit: parameters should be named

https://codereview.chromium.org/61883006/diff/220001/cc/layers/layer_impl.cc
File cc/layers/layer_impl.cc (right):

https://codereview.chromium.org/61883006/diff/220001/cc/layers/layer_impl.cc#...
cc/layers/layer_impl.cc:1355: debug_info_->AppendAsTraceFormat(&str);
You could at least hide this internally with a debug info AsValue function?

https://codereview.chromium.org/61883006/diff/220001/webkit/renderer/composit...
File webkit/renderer/compositor_bindings/web_layer_impl.cc (right):

https://codereview.chromium.org/61883006/diff/220001/webkit/renderer/composit...
webkit/renderer/compositor_bindings/web_layer_impl.cc:388: delete debug_info_;
Should debug_info_ be a scoped_ptr member since it owns it?

Also, can you leave a comment in the interface that this is an ownership
transfer?

https://codereview.chromium.org/61883006/diff/220001/webkit/renderer/composit...
webkit/renderer/compositor_bindings/web_layer_impl.cc:393: void
WebLayerImpl::setDebugInfo(
So right now this is Blink pushing debug info into cc.  Am I right in understand
that you want to make this pull, like the debug name?  (Also, is the name going
to be wrapped into debug info eventually as well?)

[chrishtr_gmail.com, 2013-11-25 22:48:25]

https://codereview.chromium.org/61883006/diff/220001/cc/layers/layer.cc
File cc/layers/layer.cc (right):

https://codereview.chromium.org/61883006/diff/220001/cc/layers/layer.cc#newco...
cc/layers/layer.cc:933: layer->SetDebugInfo(debug_info_);
On 2013/11/25 20:16:45, enne wrote:
> ConvertableToTraceFormat is not thread-safe refcounted.  This seems a little
> dodgy.

Good catch. I'll try the approach we discussed offline of adding ::AsValue to
the debug info object.

https://codereview.chromium.org/61883006/diff/220001/cc/layers/layer.h
File cc/layers/layer.h (right):

https://codereview.chromium.org/61883006/diff/220001/cc/layers/layer.h#newcod...
cc/layers/layer.h:442: virtual void
SetDebugInfo(base::debug::ConvertableToTraceFormat*);
On 2013/11/25 20:16:45, enne wrote:
> style nit: parameters should be named

Done.

https://codereview.chromium.org/61883006/diff/220001/cc/layers/layer_impl.cc
File cc/layers/layer_impl.cc (right):

https://codereview.chromium.org/61883006/diff/220001/cc/layers/layer_impl.cc#...
cc/layers/layer_impl.cc:1355: debug_info_->AppendAsTraceFormat(&str);
On 2013/11/25 20:16:45, enne wrote:
> You could at least hide this internally with a debug info AsValue function?

Adding AsValue to ConvertableToTraceFormat would work. Let me try that.

https://codereview.chromium.org/61883006/diff/220001/webkit/renderer/composit...
File webkit/renderer/compositor_bindings/web_layer_impl.cc (right):

https://codereview.chromium.org/61883006/diff/220001/webkit/renderer/composit...
webkit/renderer/compositor_bindings/web_layer_impl.cc:388: delete debug_info_;
On 2013/11/25 20:16:45, enne wrote:
> Should debug_info_ be a scoped_ptr member since it owns it?
> 
> Also, can you leave a comment in the interface that this is an ownership
> transfer?

Done.

https://codereview.chromium.org/61883006/diff/220001/webkit/renderer/composit...
webkit/renderer/compositor_bindings/web_layer_impl.cc:393: void
WebLayerImpl::setDebugInfo(
On 2013/11/25 20:16:45, enne wrote:
> So right now this is Blink pushing debug info into cc.  Am I right in
understand
> that you want to make this pull, like the debug name?  (Also, is the name
going
> to be wrapped into debug info eventually as well?)

No, I don't want it to be pull right now.

Putting debug name into debug info sounds like a good idea. I can add a TODO if
you  want?

[enne (OOO), 2013-11-25 22:49:32]

https://codereview.chromium.org/61883006/diff/220001/webkit/renderer/composit...
File webkit/renderer/compositor_bindings/web_layer_impl.cc (right):

https://codereview.chromium.org/61883006/diff/220001/webkit/renderer/composit...
webkit/renderer/compositor_bindings/web_layer_impl.cc:393: void
WebLayerImpl::setDebugInfo(
On 2013/11/25 22:48:25, chrishtr wrote:

> Putting debug name into debug info sounds like a good idea. I can add a TODO
if
> you  want?

sgtm

[chrishtr_gmail.com, 2013-11-26 21:49:03]

I changed to the get rather than set pattern, as we discussed offline.
Everything works.

@enne: the layer_impl.cc change you requested to abstract away the json encode
and decode as value stuff is not done. But I fear changing that to fix would be
a bit invasive in Value classes or elsewhere. Ok to do as a followup?

https://codereview.chromium.org/61883006/diff/220001/cc/layers/layer.cc
File cc/layers/layer.cc (right):

https://codereview.chromium.org/61883006/diff/220001/cc/layers/layer.cc#newco...
cc/layers/layer.cc:933: layer->SetDebugInfo(debug_info_);
On 2013/11/25 22:48:25, chrishtr wrote:
> On 2013/11/25 20:16:45, enne wrote:
> > ConvertableToTraceFormat is not thread-safe refcounted.  This seems a little
> > dodgy.
> 
> Good catch. I'll try the approach we discussed offline of adding ::AsValue to
> the debug info object.

Updated to not store the debug_Info_ object at all here.

[commit-bot: I haz the power, 2013-11-27 17:41:01]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/[email protected]/61883006/320001

[commit-bot: I haz the power, 2013-11-27 17:58:56]

Retried try job too often on chromium_presubmit for step(s) presubmit
http://build.chromium.org/p/tryserver.chromium/buildstatus?builder=chromium_p...

[commit-bot: I haz the power, 2013-12-02 18:05:22]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/[email protected]/61883006/320001

[commit-bot: I haz the power, 2013-12-02 18:29:48]

Retried try job too often on chromium_presubmit for step(s) presubmit
http://build.chromium.org/p/tryserver.chromium/buildstatus?builder=chromium_p...

[commit-bot: I haz the power, 2013-12-02 18:56:17]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/[email protected]/61883006/340001

[commit-bot: I haz the power, 2013-12-02 19:16:46]

Retried try job too often on chromium_presubmit for step(s) presubmit
http://build.chromium.org/p/tryserver.chromium/buildstatus?builder=chromium_p...

[commit-bot: I haz the power, 2013-12-02 19:45:35]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/[email protected]/61883006/360001

[danakj, 2013-12-02 19:46:59]

Please see the PRESUBMIT bot output:

[email protected] is not in AUTHORS file. If you are a new contributor, please
visit
http://www.chromium.org/developers/contributing-code and read the "Legal"
section
If you are a chromite, verify the contributor signed the CLA.

[chrishtr_gmail.com, 2013-12-02 20:24:19]

I figured that one out in the latest run - added myself to AUTHORS and
filled out the legal form. In earlier runs I had wrongly assumed that since
it was a "warning" it would not block presubmit.


On Mon, Dec 2, 2013 at 11:47 AM, <[email protected]> wrote:

> Please see the PRESUBMIT bot output:
>
> [email protected] is not in AUTHORS file. If you are a new contributor,
> please
> visit
> http://www.chromium.org/developers/contributing-code and read the "Legal"
> section
> If you are a chromite, verify the contributor signed the CLA.
>
> https://codereview.chromium.org/61883006/
>

To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].

[danakj, 2013-12-02 20:27:51]

On 2013/12/02 20:24:19, chrishtr wrote:
> I figured that one out in the latest run - added myself to AUTHORS and
> filled out the legal form. In earlier runs I had wrongly assumed that since
> it was a "warning" it would not block presubmit.

Ah, good thanks. Rechecked CQ.

[commit-bot: I haz the power, 2013-12-02 20:31:24]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/[email protected]/61883006/360001

[commit-bot: I haz the power, 2013-12-02 21:05:29]

Failed to trigger a try job on win_x64_rel
HTTP Error 400: Bad Request

[commit-bot: I haz the power, 2013-12-02 21:05:41]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/[email protected]/61883006/380001

[commit-bot: I haz the power, 2013-12-02 23:16:51]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/[email protected]/61883006/400001

[commit-bot: I haz the power, 2013-12-02 23:33:23]

Retried try job too often on chromium_presubmit for step(s) presubmit
http://build.chromium.org/p/tryserver.chromium/buildstatus?builder=chromium_p...

[danakj, 2013-12-02 23:37:41]

https://codereview.chromium.org/61883006/diff/400001/cc/layers/layer_client.h
File cc/layers/layer_client.h (right):

https://codereview.chromium.org/61883006/diff/400001/cc/layers/layer_client.h...
cc/layers/layer_client.h:25: // If not, returns NULL. If the returned pointer is
non-NULL, the caller takes
Why is this returning a raw pointer instead of a scoped_ptr?

[pdr., 2013-12-02 23:43:11]

I think we need an OWNER lgtm for these changes before the presubmit script will
be happy:
    ui/compositor/layer.cc
    ui/compositor/layer.h

[danakj, 2013-12-02 23:44:27]

I'll be happy to review, but I have a question about this API, in previous
message.

[chrishtr_gmail.com, 2013-12-02 23:55:18]

Thanks for the quick reply.

https://codereview.chromium.org/61883006/diff/400001/cc/layers/layer_client.h
File cc/layers/layer_client.h (right):

https://codereview.chromium.org/61883006/diff/400001/cc/layers/layer_client.h...
cc/layers/layer_client.h:25: // If not, returns NULL. If the returned pointer is
non-NULL, the caller takes
On 2013/12/02 23:37:42, danakj wrote:
> Why is this returning a raw pointer instead of a scoped_ptr?

1. Consistency w/the Blink-side method, which needs to return a raw ptr because
the codebases have separate scoped_refptr implementations.

2. This pointer is being passed across to the impl thread. scoped_refptr is not
thread safe, and anyone who stores it would need to be careful to do so in a
thread-safe manner, including not storing any refptr on both the main and impl
threads. This feels a bit safer.

[danakj, 2013-12-02 23:57:27]

https://codereview.chromium.org/61883006/diff/400001/cc/layers/layer_client.h
File cc/layers/layer_client.h (right):

https://codereview.chromium.org/61883006/diff/400001/cc/layers/layer_client.h...
cc/layers/layer_client.h:25: // If not, returns NULL. If the returned pointer is
non-NULL, the caller takes
On 2013/12/02 23:55:19, chrishtr wrote:
> On 2013/12/02 23:37:42, danakj wrote:
> > Why is this returning a raw pointer instead of a scoped_ptr?
> 
> 1. Consistency w/the Blink-side method, which needs to return a raw ptr
because
> the codebases have separate scoped_refptr implementations.
> 
> 2. This pointer is being passed across to the impl thread. scoped_refptr is
not
> thread safe, and anyone who stores it would need to be careful to do so in a
> thread-safe manner, including not storing any refptr on both the main and impl
> threads. This feels a bit safer.
> 
> 

Note, I would like this to be a scoped_ptr, not a scoped_refptr. scoped_ptr is
single-ownership. You can convert the raw pointer into a scoped_ptr in the
web_compositor_bindings layer (web_layer_impl.cc) and then you don't need any
comments or ambiguities about ownership. WDYT?

[chrishtr_gmail.com, 2013-12-03 00:00:10]

https://codereview.chromium.org/61883006/diff/400001/cc/layers/layer_client.h
File cc/layers/layer_client.h (right):

https://codereview.chromium.org/61883006/diff/400001/cc/layers/layer_client.h...
cc/layers/layer_client.h:25: // If not, returns NULL. If the returned pointer is
non-NULL, the caller takes
On 2013/12/02 23:57:28, danakj wrote:
> On 2013/12/02 23:55:19, chrishtr wrote:
> > On 2013/12/02 23:37:42, danakj wrote:
> > > Why is this returning a raw pointer instead of a scoped_ptr?
> > 
> > 1. Consistency w/the Blink-side method, which needs to return a raw ptr
> because
> > the codebases have separate scoped_refptr implementations.
> > 
> > 2. This pointer is being passed across to the impl thread. scoped_refptr is
> not
> > thread safe, and anyone who stores it would need to be careful to do so in a
> > thread-safe manner, including not storing any refptr on both the main and
impl
> > threads. This feels a bit safer.
> > 
> > 
> 
> Note, I would like this to be a scoped_ptr, not a scoped_refptr. scoped_ptr is
> single-ownership. You can convert the raw pointer into a scoped_ptr in the
> web_compositor_bindings layer (web_layer_impl.cc) and then you don't need any
> comments or ambiguities about ownership. WDYT?

I see.


Hmm. Does scoped_ptr work in this case? ConvertableToTraceFormat inherits from
RefCounted<ConvertableToTraceFormat>. I am not sure if that breaks things.

[chrishtr_gmail.com, 2013-12-03 00:02:22]

https://codereview.chromium.org/61883006/diff/400001/cc/layers/layer_client.h
File cc/layers/layer_client.h (right):

https://codereview.chromium.org/61883006/diff/400001/cc/layers/layer_client.h...
cc/layers/layer_client.h:25: // If not, returns NULL. If the returned pointer is
non-NULL, the caller takes
On 2013/12/03 00:00:11, chrishtr wrote:
> On 2013/12/02 23:57:28, danakj wrote:
> > On 2013/12/02 23:55:19, chrishtr wrote:
> > > On 2013/12/02 23:37:42, danakj wrote:
> > > > Why is this returning a raw pointer instead of a scoped_ptr?
> > > 
> > > 1. Consistency w/the Blink-side method, which needs to return a raw ptr
> > because
> > > the codebases have separate scoped_refptr implementations.
> > > 
> > > 2. This pointer is being passed across to the impl thread. scoped_refptr
is
> > not
> > > thread safe, and anyone who stores it would need to be careful to do so in
a
> > > thread-safe manner, including not storing any refptr on both the main and
> impl
> > > threads. This feels a bit safer.
> > > 
> > > 
> > 
> > Note, I would like this to be a scoped_ptr, not a scoped_refptr. scoped_ptr
is
> > single-ownership. You can convert the raw pointer into a scoped_ptr in the
> > web_compositor_bindings layer (web_layer_impl.cc) and then you don't need
any
> > comments or ambiguities about ownership. WDYT?
> 
> I see.
> 
> 
> Hmm. Does scoped_ptr work in this case? ConvertableToTraceFormat inherits from
> RefCounted<ConvertableToTraceFormat>. I am not sure if that breaks things.

Indeed it does break:


../../base/memory/scoped_ptr.h:313:3: error: static_assert failed
"T_is_refcounted_type_and_needs_scoped_refptr"
  COMPILE_ASSERT(base::internal::IsNotRefCounted<T>::value,
  ^              ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
../../base/basictypes.h:224:35: note: expanded from macro 'COMPILE_ASSERT'
#define COMPILE_ASSERT(expr, msg) static_assert(expr, #msg)

[danakj, 2013-12-03 00:03:05]

On 2013/12/03 00:00:10, chrishtr wrote:
> https://codereview.chromium.org/61883006/diff/400001/cc/layers/layer_client.h
> File cc/layers/layer_client.h (right):
> 
>
https://codereview.chromium.org/61883006/diff/400001/cc/layers/layer_client.h...
> cc/layers/layer_client.h:25: // If not, returns NULL. If the returned pointer
is
> non-NULL, the caller takes
> On 2013/12/02 23:57:28, danakj wrote:
> > On 2013/12/02 23:55:19, chrishtr wrote:
> > > On 2013/12/02 23:37:42, danakj wrote:
> > > > Why is this returning a raw pointer instead of a scoped_ptr?
> > > 
> > > 1. Consistency w/the Blink-side method, which needs to return a raw ptr
> > because
> > > the codebases have separate scoped_refptr implementations.
> > > 
> > > 2. This pointer is being passed across to the impl thread. scoped_refptr
is
> > not
> > > thread safe, and anyone who stores it would need to be careful to do so in
a
> > > thread-safe manner, including not storing any refptr on both the main and
> impl
> > > threads. This feels a bit safer.
> > > 
> > > 
> > 
> > Note, I would like this to be a scoped_ptr, not a scoped_refptr. scoped_ptr
is
> > single-ownership. You can convert the raw pointer into a scoped_ptr in the
> > web_compositor_bindings layer (web_layer_impl.cc) and then you don't need
any
> > comments or ambiguities about ownership. WDYT?
> 
> I see.
> 
> 
> Hmm. Does scoped_ptr work in this case? ConvertableToTraceFormat inherits from
> RefCounted<ConvertableToTraceFormat>. I am not sure if that breaks things.

Oh I see, no it wouldn't.

But if you're passing ownership of it, that means you've gone into the land of
manually adding/removing ref counts which is scary.

Why can't you pass it around as a scoped_refptr after all and use a
base::ThreadChecker to verify that it is not used on the wrong thread?

[chrishtr_gmail.com, 2013-12-03 00:10:49]

On 2013/12/03 00:03:05, danakj wrote:
> On 2013/12/03 00:00:10, chrishtr wrote:
> >
https://codereview.chromium.org/61883006/diff/400001/cc/layers/layer_client.h
> > File cc/layers/layer_client.h (right):
> > 
> >
>
https://codereview.chromium.org/61883006/diff/400001/cc/layers/layer_client.h...
> > cc/layers/layer_client.h:25: // If not, returns NULL. If the returned
pointer
> is
> > non-NULL, the caller takes
> > On 2013/12/02 23:57:28, danakj wrote:
> > > On 2013/12/02 23:55:19, chrishtr wrote:
> > > > On 2013/12/02 23:37:42, danakj wrote:
> > > > > Why is this returning a raw pointer instead of a scoped_ptr?
> > > > 
> > > > 1. Consistency w/the Blink-side method, which needs to return a raw ptr
> > > because
> > > > the codebases have separate scoped_refptr implementations.
> > > > 
> > > > 2. This pointer is being passed across to the impl thread. scoped_refptr
> is
> > > not
> > > > thread safe, and anyone who stores it would need to be careful to do so
in
> a
> > > > thread-safe manner, including not storing any refptr on both the main
and
> > impl
> > > > threads. This feels a bit safer.
> > > > 
> > > > 
> > > 
> > > Note, I would like this to be a scoped_ptr, not a scoped_refptr.
scoped_ptr
> is
> > > single-ownership. You can convert the raw pointer into a scoped_ptr in the
> > > web_compositor_bindings layer (web_layer_impl.cc) and then you don't need
> any
> > > comments or ambiguities about ownership. WDYT?
> > 
> > I see.
> > 
> > 
> > Hmm. Does scoped_ptr work in this case? ConvertableToTraceFormat inherits
from
> > RefCounted<ConvertableToTraceFormat>. I am not sure if that breaks things.
> 
> Oh I see, no it wouldn't.
> 
> But if you're passing ownership of it, that means you've gone into the land of
> manually adding/removing ref counts which is scary.
> 
> Why can't you pass it around as a scoped_refptr after all and use a
> base::ThreadChecker to verify that it is not used on the wrong thread?

Protecting the call to AppendAsTraceFormat in that way would work. And you think
the benefit of less risk of memory leak outweighs any risk of race conditions
between threads? I'm happy to go with your judgement on this..

[danakj, 2013-12-03 00:13:00]

On Mon, Dec 2, 2013 at 7:10 PM, <[email protected]> wrote:

> On 2013/12/03 00:03:05, danakj wrote:
>
>> On 2013/12/03 00:00:10, chrishtr wrote:
>> >
>>
> https://codereview.chromium.org/61883006/diff/400001/cc/
> layers/layer_client.h
>
>> > File cc/layers/layer_client.h (right):
>> >
>> >
>>
>
> https://codereview.chromium.org/61883006/diff/400001/cc/
> layers/layer_client.h#newcode25
>
>> > cc/layers/layer_client.h:25: // If not, returns NULL. If the returned
>>
> pointer
>
>> is
>> > non-NULL, the caller takes
>> > On 2013/12/02 23:57:28, danakj wrote:
>> > > On 2013/12/02 23:55:19, chrishtr wrote:
>> > > > On 2013/12/02 23:37:42, danakj wrote:
>> > > > > Why is this returning a raw pointer instead of a scoped_ptr?
>> > > >
>> > > > 1. Consistency w/the Blink-side method, which needs to return a raw
>> ptr
>> > > because
>> > > > the codebases have separate scoped_refptr implementations.
>> > > >
>> > > > 2. This pointer is being passed across to the impl thread.
>> scoped_refptr
>> is
>> > > not
>> > > > thread safe, and anyone who stores it would need to be careful to
>> do so
>>
> in
>
>> a
>> > > > thread-safe manner, including not storing any refptr on both the
>> main
>>
> and
>
>> > impl
>> > > > threads. This feels a bit safer.
>> > > >
>> > > >
>> > >
>> > > Note, I would like this to be a scoped_ptr, not a scoped_refptr.
>>
> scoped_ptr
>
>> is
>> > > single-ownership. You can convert the raw pointer into a scoped_ptr
>> in the
>> > > web_compositor_bindings layer (web_layer_impl.cc) and then you don't
>> need
>> any
>> > > comments or ambiguities about ownership. WDYT?
>> >
>> > I see.
>> >
>> >
>> > Hmm. Does scoped_ptr work in this case? ConvertableToTraceFormat
>> inherits
>>
> from
>
>> > RefCounted<ConvertableToTraceFormat>. I am not sure if that breaks
>> things.
>>
>
>  Oh I see, no it wouldn't.
>>
>
>  But if you're passing ownership of it, that means you've gone into the
>> land of
>> manually adding/removing ref counts which is scary.
>>
>
>  Why can't you pass it around as a scoped_refptr after all and use a
>> base::ThreadChecker to verify that it is not used on the wrong thread?
>>
>
> Protecting the call to AppendAsTraceFormat in that way would work. And you
> think
> the benefit of less risk of memory leak outweighs any risk of race
> conditions
> between threads? I'm happy to go with your judgement on this..
>

From my own experience in the code, pointer ownership should be strictly
enforced by types whenever possible. And thread safety can be enforced by
runtime checks as ThreadChecker.

I don't think passing a raw pointer adds any thread safety, you could just
hold onto the raw pointer as easily as you could hold onto a reference. So
ya, I'd prefer that.


>
> https://codereview.chromium.org/61883006/
>

To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].

[chrishtr_gmail.com, 2013-12-03 00:29:07]

On 2013/12/03 00:13:00, danakj wrote:
> On Mon, Dec 2, 2013 at 7:10 PM, <mailto:[email protected]> wrote:
> 
> > On 2013/12/03 00:03:05, danakj wrote:
> >
> >> On 2013/12/03 00:00:10, chrishtr wrote:
> >> >
> >>
> > https://codereview.chromium.org/61883006/diff/400001/cc/
> > layers/layer_client.h
> >
> >> > File cc/layers/layer_client.h (right):
> >> >
> >> >
> >>
> >
> > https://codereview.chromium.org/61883006/diff/400001/cc/
> > layers/layer_client.h#newcode25
> >
> >> > cc/layers/layer_client.h:25: // If not, returns NULL. If the returned
> >>
> > pointer
> >
> >> is
> >> > non-NULL, the caller takes
> >> > On 2013/12/02 23:57:28, danakj wrote:
> >> > > On 2013/12/02 23:55:19, chrishtr wrote:
> >> > > > On 2013/12/02 23:37:42, danakj wrote:
> >> > > > > Why is this returning a raw pointer instead of a scoped_ptr?
> >> > > >
> >> > > > 1. Consistency w/the Blink-side method, which needs to return a raw
> >> ptr
> >> > > because
> >> > > > the codebases have separate scoped_refptr implementations.
> >> > > >
> >> > > > 2. This pointer is being passed across to the impl thread.
> >> scoped_refptr
> >> is
> >> > > not
> >> > > > thread safe, and anyone who stores it would need to be careful to
> >> do so
> >>
> > in
> >
> >> a
> >> > > > thread-safe manner, including not storing any refptr on both the
> >> main
> >>
> > and
> >
> >> > impl
> >> > > > threads. This feels a bit safer.
> >> > > >
> >> > > >
> >> > >
> >> > > Note, I would like this to be a scoped_ptr, not a scoped_refptr.
> >>
> > scoped_ptr
> >
> >> is
> >> > > single-ownership. You can convert the raw pointer into a scoped_ptr
> >> in the
> >> > > web_compositor_bindings layer (web_layer_impl.cc) and then you don't
> >> need
> >> any
> >> > > comments or ambiguities about ownership. WDYT?
> >> >
> >> > I see.
> >> >
> >> >
> >> > Hmm. Does scoped_ptr work in this case? ConvertableToTraceFormat
> >> inherits
> >>
> > from
> >
> >> > RefCounted<ConvertableToTraceFormat>. I am not sure if that breaks
> >> things.
> >>
> >
> >  Oh I see, no it wouldn't.
> >>
> >
> >  But if you're passing ownership of it, that means you've gone into the
> >> land of
> >> manually adding/removing ref counts which is scary.
> >>
> >
> >  Why can't you pass it around as a scoped_refptr after all and use a
> >> base::ThreadChecker to verify that it is not used on the wrong thread?
> >>
> >
> > Protecting the call to AppendAsTraceFormat in that way would work. And you
> > think
> > the benefit of less risk of memory leak outweighs any risk of race
> > conditions
> > between threads? I'm happy to go with your judgement on this..
> >
> 
> From my own experience in the code, pointer ownership should be strictly
> enforced by types whenever possible. And thread safety can be enforced by
> runtime checks as ThreadChecker.
> 
> I don't think passing a raw pointer adds any thread safety, you could just
> hold onto the raw pointer as easily as you could hold onto a reference. So
> ya, I'd prefer that.
> 
> 
> >
> > https://codereview.chromium.org/61883006/
> >
> 
> To unsubscribe from this group and stop receiving emails from it, send an
email
> to mailto:[email protected].

Done, please take another look.

[danakj, 2013-12-03 00:38:18]

Thanks, LGTM

https://codereview.chromium.org/61883006/diff/420001/ui/compositor/layer.cc
File ui/compositor/layer.cc (right):

https://codereview.chromium.org/61883006/diff/420001/ui/compositor/layer.cc#n...
ui/compositor/layer.cc:671: return
scoped_refptr<base::debug::ConvertableToTraceFormat>(NULL);
Maybe a TODO here to return some useful data so we can make use of this feature
for UI compositor, if that sounds right to you?

https://codereview.chromium.org/61883006/diff/420001/webkit/renderer/composit...
File webkit/renderer/compositor_bindings/web_layer_impl.cc (right):

https://codereview.chromium.org/61883006/diff/420001/webkit/renderer/composit...
webkit/renderer/compositor_bindings/web_layer_impl.cc:401: return
scoped_refptr<base::debug::ConvertableToTraceFormat>(
nit: you don't need to wrap this with the constructor, you can implicitly
convert T* to scoped_refptr<T>().

You need {} here and on the else{} if you make this span multiple lines.

[chrishtr_gmail.com, 2013-12-03 00:44:07]

Could you also check the CQ box for me?

https://codereview.chromium.org/61883006/diff/420001/ui/compositor/layer.cc
File ui/compositor/layer.cc (right):

https://codereview.chromium.org/61883006/diff/420001/ui/compositor/layer.cc#n...
ui/compositor/layer.cc:671: return
scoped_refptr<base::debug::ConvertableToTraceFormat>(NULL);
On 2013/12/03 00:38:18, danakj wrote:
> Maybe a TODO here to return some useful data so we can make use of this
feature
> for UI compositor, if that sounds right to you?

Done.

https://codereview.chromium.org/61883006/diff/420001/webkit/renderer/composit...
File webkit/renderer/compositor_bindings/web_layer_impl.cc (right):

https://codereview.chromium.org/61883006/diff/420001/webkit/renderer/composit...
webkit/renderer/compositor_bindings/web_layer_impl.cc:401: return
scoped_refptr<base::debug::ConvertableToTraceFormat>(
On 2013/12/03 00:38:18, danakj wrote:
> nit: you don't need to wrap this with the constructor, you can implicitly
> convert T* to scoped_refptr<T>().
> 
> You need {} here and on the else{} if you make this span multiple lines.

Done.

[danakj, 2013-12-03 00:44:42]

On 2013/12/03 00:44:07, chrishtr wrote:
> Could you also check the CQ box for me?

Done. :)

[commit-bot: I haz the power, 2013-12-03 00:45:09]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/[email protected]/61883006/460001

[commit-bot: I haz the power, 2013-12-03 03:53:29]

Change committed as 238297