[blink-dev] Call for lightning talks at BlinkOn18!

[Kentaro Hara]

Hi

I'm happy to announce that lightning talks are coming back to BlinkOn 18!
This is a great opportunity to present your projects without having a
formal session. To be inclusive for virtual attendees, Day 1 will be
in-person talks and Day 2 will be pre-recorded talks.

The rule is simple:


   -

   Each talk should be kept to 3 mins.
   -

   If you are presenting in-person, add your name to the sheet
   
<https://docs.google.com/spreadsheets/d/1otWvI2raI04IW-xaZVTQV12vr9gnxN9MaSefVxkALpc/edit#gid=0>
   by Oct 3 and upload your deck by Oct 10. Otherwise, add your name and
   upload the pre-recorded video by Oct 3.
   -

   There are 26 slots in total. First come, first served.
   -

   You can talk about anything about Blink. Any crazy ideas are welcome!


Let's make the hybrid BlinkOn more exciting with the lightning talk
sessions :)

Kentaro Hara on behalf of the BlinkOn planning team


-- 
Kentaro Hara, Tokyo

-- 
You received this message because you are subscribed to the Google Groups 
"blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to blink-dev+unsubscr...@chromium.org.
To view this discussion on the web visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CABg10jyVVpxUAjZS6xhGqJNZyqWZ%2B%3DSFq9ML%2B-eZC0qYoELN5g%40mail.gmail.com.

[blink-dev] Call for BlinkOn 17 lightning talks!!

[Kentaro Hara]

Hi,

I'm happy to announce that lightning talks are coming back to BlinkOn 17!
This is a great opportunity to present your projects without having a
formal session. To be inclusive for virtual attendees, Day 1 will be a mix
of in-person talks and pre-recorded talks, and Day 2 will be pre-recorded
talks only.

The rule is simple:


   -

   Each talk should be kept to 3 mins.
   -

   If you are presenting in-person, add your name to the sheet
   
<https://docs.google.com/spreadsheets/d/10-SUvJfWdYnpP2LOegQkoNHg9qofM0_Hkh8lPRAzqcw/edit#gid=0>
   by Oct 24 and upload your deck by Nov 7. Otherwise, add your name and
   upload the pre-recorded video to the sheet
   
<https://docs.google.com/spreadsheets/d/10-SUvJfWdYnpP2LOegQkoNHg9qofM0_Hkh8lPRAzqcw/edit#gid=0>
   by Oct 24.
   -

   There are 26 slots in total. First come, first served.
   -

   You can talk about anything about Blink. Any crazy ideas are welcome!


Let's make the hybrid BlinkOn more exciting with the lightning talk
sessions :)

Kentaro Hara on behalf of the BlinkOn planning team

-- 
Kentaro Hara, Tokyo

-- 
You received this message because you are subscribed to the Google Groups 
"blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to blink-dev+unsubscr...@chromium.org.
To view this discussion on the web visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CABg10jw4Xf7rEFfkPRvLD1%2ByLa4ceYSiEPZkJRct%2BerpucketQ%40mail.gmail.com.

Re: [blink-dev] Debugging compressed pointers in Blink

[Kentaro Hara]

+Michael Lippautz 

2022年9月22日(木) 4:01 'Daniel Libby' via blink-dev :

> https://crrev.com/c/3835682 enabled pointer compression for Blink
> Member<> pointers. How are folks handling these while debugging (either
> live or crash dumps)? Is there some tooling available that will look up and
> apply the cage base?
>
> I didn't see anything mentioned in
> https://docs.google.com/document/d/1neGN8Jq-1JLrWK3cvwRIfrSjLgE0Srjv-uq7Ze38Iao/edit#
> but maybe there are better known tools/techniques from v8 (which IIUC has
> had compressed pointers for some time now).
>
> --
> You received this message because you are subscribed to the Google Groups
> "blink-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to blink-dev+unsubscr...@chromium.org.
> To view this discussion on the web visit
> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/4b3e5bbb-134a-4483-9a1e-8e33fbc6f38en%40chromium.org
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to blink-dev+unsubscr...@chromium.org.
To view this discussion on the web visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CABg10jxSdx3JzWvTC2j7RUEcw01P9gTRhT%3DnftwehY3br4qNWA%40mail.gmail.com.

Re: [chromium-dev] Re: [blink-dev] Inactive OWNERS cleanup

['Kentaro Hara' via blink-dev]

Hi

Thanks all for the thoughts! I discussed with some of the people on this
thread and Eng Review offline.

It's important to keep OWNERS files up-dated. OWNERS should include people
who are meeting the owner's expectations
<https://chromium.googlesource.com/chromium/src/+/refs/heads/main/docs/code_reviews.md#expectations-of-owners>
("Have
committed or reviewed substantial work to the affected directory within the
last ninety days", "Have the bandwidth to contribute to reviews in a timely
manner"). The consumers of OWNERS shouldn't need to care what's happening
with individuals on that list, and should be able to get useful, fast
turnaround time from them. I get the argument that we shouldn't penalize
folks on leaves, however, we also have to make sure that the system doesn't
punish everybody by having a number of absent owners, so I'm still in favor
of removing absent owners and we'd just add them back in when they're back
and active again.

On the other hand, I agree with the feedback that removing inactive owners
unconditionally is too aggressive (thanks for the feedback!). So I propose
going with the following plan:

1) Add this policy
<https://chromium-review.googlesource.com/c/chromium/src/+/3801506> to
code_reviews.md. The policy says that if you are removed while you were on
a leave, you can re-add yourself when you are back.
2) Use the (already existing) automated owner removal tool and let it
create a CL to *remove owners who made 0 commits / reviews to Chromium in
the past 12 months (2021/7/26 - 2022/7/26)*. This will be a strong signal
to indicate inactive owners. There are 320 owners
<https://docs.google.com/spreadsheets/d/1gJbXzTaoITvCDmQaqMmGCvfOngrcFtMPmMsGhHgEV_4/edit#gid=1293326884>
.
3) The CL adds existing owners of the directory (including the owner to be
removed) to a reviewer list. The CL description clearly asks the reviewers
to check that the removed owner is not on a leave. The CL is committed
after getting an LGTM from one of the reviewers.
4) If an owner is mistakenly removed while they are on a leave (which is
not likely to happen due to 3)), they can re-add themselves according to the
policy <https://chromium-review.googlesource.com/c/chromium/src/+/3801506>.

It's possible that some owners made 0 commits / reviews to Chromium in the
past 12 months because their directories are under maintenance mode and
didn't have many CLs. In this case, they (or other owners in the directory)
can say Code-Review -1 in 3).

If you have any concerns, please let me know.

Thanks!



On Fri, Aug 5, 2022 at 2:01 PM Andy Perelson  wrote:

> Hi folks,
>
> A fair bit of the feedback on Kentaro's proposal has focused on improving
> Owners suggestions and better handling OOO Owners. We do believe there's a
> lot of room to improve owners suggestions to help improve review time. OOO
> is one aspect, but you could also imagine such a system taking into account
> time zones, review loads, etc. It's an area we'd like to improve on but
> also a complicated one. I can't promise specific features or a timeline at
> this stage, but know that we hear and agree with the feedback that this
> would be a useful area to improve that could positively help review times.
> And one we've been thinking about for a while.
>
> Thanks,
>
> Andy
> On behalf of the Chrome Ops Source team
>
> On Thu, Aug 4, 2022 at 5:43 PM Jayson Adams  wrote:
>
>> This policy, despite the proposed disclaimer paragraph, still feels like
>> it penalizes people who are on leave. Whether it's parental or disability
>> or any other kind of leave, no one should have to jump through hoops upon
>> their return to restart their job (or I guess why not also remove
>> committer status, in the interest of making things tidy, while you're at
>> it?).
>>
>> Given that your updated list only contains 47 owners, it seems like
>> checking each one to see if they're on leave (and removing them if so)
>> would not be that big of an issue.
>>
>> On Mon, Aug 1, 2022 at 6:57 AM Kentaro Hara  wrote:
>>
>>> Discussed with Peter and Glen offline.
>>>
>>> I excluded per-file owners and updated the spreadsheet
>>> <https://docs.google.com/spreadsheets/d/1gJbXzTaoITvCDmQaqMmGCvfOngrcFtMPmMsGhHgEV_4/edit#gid=0&fvid=432067682>
>>> (based on the data as of July 26 when I announced this).
>>>
>>> To mitigate the concern about removing long-time OOO owners and making
>>> them feel uncomfortable about re-adding themselves when they are back, we
>>> decided to add the following paragraph
>>> <https://chromium-review.googlesource.com/c/chromium/src/+/3801506> to
>>> the owners guidelin

Re: [chromium-dev] Re: [blink-dev] Inactive OWNERS cleanup

[Kentaro Hara]

Discussed with Peter and Glen offline.

I excluded per-file owners and updated the spreadsheet
<https://docs.google.com/spreadsheets/d/1gJbXzTaoITvCDmQaqMmGCvfOngrcFtMPmMsGhHgEV_4/edit#gid=0&fvid=432067682>
(based on the data as of July 26 when I announced this).

To mitigate the concern about removing long-time OOO owners and making them
feel uncomfortable about re-adding themselves when they are back, we
decided to add the following paragraph
<https://chromium-review.googlesource.com/c/chromium/src/+/3801506> to the
owners guideline (which is under review):

"For the purpose of not slowing down code review latency, Chromium removes
inactive owners (e.g., those who made no contributions in the past 6
months) on a regular basis. The script does not take into account personal
situations like a long leave and thus can be wrong. If you are removed by
the automated process for a wrong reason while you are being a good owner,
you can create a CL to re-add yourself to OWNERS and land after getting
local owner's approval. You just need to explain the reason (e.g., long
leave) and don't need to make a substantial contribution to become an owner
again."

Manuel:

> Just for completeness, there are some OWNERS files that require a
> nomination process. At least third_party/blink/renderer/core/OWNERS
> requires that.


I hope the above process mitigates the concern.

Matt:

> Maybe it would make more sense to identify OWNERS who are not active
> globally in chrome/, instead of owners not active in a particular
> directory?  How common are OWNERS active in Chrome, but high latency only
> for specific directories?


FWIW I created a list
<https://docs.google.com/spreadsheets/d/1gJbXzTaoITvCDmQaqMmGCvfOngrcFtMPmMsGhHgEV_4/edit#gid=1360797710>
of OWNERS who made no commits / reviews in the past 6 months (as of July
26). We could take an intersection between this list and my proposed list
but I'd prefer simply going with my proposed list with the above mitigation
process.

Peter:

> I don't think that 85/6850 OWNERS entries are a large enough problem to
> bypass local owner approval for this (i.e. land it unconditionally). If
> some of them are owners in very active folders and have had a lot of
> reviews assigned to them, sure. This is about 1% of ownership entries if
> I'm understanding this correctly. How badly are they contributing to review
> latency in order to override "and they are not on a leave during that time"
> as a policy? I like this policy, and it's supposed to still be the policy.


We are removing (only) 85 owners (47 owners after per-file owners are
excluded) because we removed ~500 owners one year ago. I think it's
important to run this cleanup process periodically to keep the codebase
up-dated. Our Chrome infra team is now brainstorming an idea to automate
the process of removing inactive owners.


I'm planning to execute the cleanup next week. If you have any questions,
please let me know. Thanks!



On Sat, Jul 30, 2022 at 3:56 AM Peter Boström  wrote:

> I specifically disagree with the "for this cycle, I'm planning to remove
> the inactive owners unconditionally" bit. If you suggest this removal but
> you defer to local OWNERS to make the call I think that's fine to send out
> removal CLs for. I would encourage you and/or the reviewers to look at the
> removed owner's calendar if they're internal and confirm that they've not
> been on long-term leave.
>
> I don't think that 85/6850 OWNERS entries are a large enough problem to
> bypass local owner approval for this (i.e. land it unconditionally). If
> some of them are owners in very active folders and have had a lot of
> reviews assigned to them, sure. This is about 1% of ownership entries if
> I'm understanding this correctly. How badly are they contributing to review
> latency in order to override "and they are not on a leave during that time"
> as a policy? I like this policy, and it's supposed to still be the policy.
>
> If any of these OWNERS entries had a significant amount of reviews
> assigned to them during this period (i.e. sorta-evidence of latency), you
> could use that as additional justification in the CLs to get the OWNERS to
> approve the (possibly temporary) removal.
>
> For fixing review latency which is the real goal presumably, I think
> handling OOO and load balancing are both more important vectors here. We
> shouldn't need to get inactive owners down to 0 to solve review latency.
>
> On Thu, Jul 28, 2022 at 6:47 PM Kentaro Hara  wrote:
>
>> +1 to improving the tool to handle OOO owners.
>>
>> Let's step back. The problem I'm solving now is: currently OWNERS files
>> contain many long-time inactive, non-OOO owners. The goal is to

Re: [chromium-dev] Re: [blink-dev] Inactive OWNERS cleanup

[Kentaro Hara]

+1 to improving the tool to handle OOO owners.

Let's step back. The problem I'm solving now is: currently OWNERS files
contain many long-time inactive, non-OOO owners. The goal is to remove
them. Do you agree with the goal?

The "long-time inactive" part is covered by looking into their review /
commit activities in the past 6 months.

The "non-OOO" part is tricky because currently there is no way to get the
information from the tool. I'm not sure if giving an option to manually
flip the decision is a great solution because if they are long-time OOO,
they are not likely to be looking at this email and get removed anyway.
Then I thought that it's more reasonable to execute the clean-up process
unconditionally while explicitly saying that they can explain the situation
and re-add themselves when they are back (where they can refer to this
email thread).

What do you think?



On Fri, Jul 29, 2022 at 1:41 AM K. Moon  wrote:

> On a related topic, one challenge that I have with OOO status is that it's
> hard to update all the places where you might want to note that (each
> Gerrit repository, Slack, external Gmail, internal Gmail, Calendar, ...).
> For Googlers, I have decent tooling for checking whether they're OOO, in my
> time zone, or whatever (although better integration would save me time),
> but if I wasn't a Googler (and didn't have access to those tools), or I
> want to check the status of a non-Googler, it's often not as easy, or
> impossible.
>
> It'd be great if there were One Tool that (opt-in) tracked OOO status in a
> centralized directory, and worked whether or not you had a Google or
> Chromium account.
>
> For parts of the tree that need to balance between a large number of
> reviewers, something like gwsq probably would be a decent solution.
> (//ipc/SECURITY_OWNERS is using this now; I think trees like //content
> would benefit as well.)
>
> On Thu, Jul 28, 2022 at 8:56 AM Peter Boström  wrote:
>
>> I agree with the policy to not remove owners because they are on leave.
>> Owners plus OOO status should inform owner selection and we still need that
>> because we shouldn't remove owners while they are out for a week but they
>> sure shouldn't be used during that week.
>>
>> If OOO is an efficient signal this should be sufficient without force
>> removing folks on leave. If OOO isn't a sufficient signal and introduces
>> review latency we should look at why that is instead and fix our tooling.
>>
>> If I may spitball another reason for latency we should maybe also surface
>> how long folks review queues are and perhaps use that to help guide owners
>> selection.
>>
>> Also because I'm already up on my soapbox, if you're fast and not
>> overloaded and want to help with the review load, please put something like
>> "fast" or "more reviews plz" in your Gerrit status to encourage more
>> reviews your way (me inspired by ellyjones@ here). Encourage others to
>> do the same and reward this as a community contribution.
>>
>> On Thu, Jul 28, 2022 at 8:15 AM K. Moon  wrote:
>>
>>> I think our owner-suggesting tooling really needs to be better about
>>> deprioritizing owners who are on leave (as well as better load balancing).
>>> I'm not sure periodically removing and re-adding owners is the right
>>> long-term fix, but it could be acceptable if we're working on better
>>> infrastructure in the meanwhile.
>>>
>>> I think another good, oft-discussed improvement would be to separate
>>> Review+1 from Owners+1. This would make the review load for owners more
>>> manageable, as they can just say that they approve of the overall change,
>>> without also marking every file they own as reviewed (and all that implies).
>>>
>>> On Thu, Jul 28, 2022 at 7:34 AM 'Matt Menke' via blink-dev <
>>> blink-dev@chromium.org> wrote:
>>>
>>>>
>>>>
>>>> On Thu, Jul 28, 2022 at 10:29 AM Ali Juma  wrote:
>>>>
>>>>>
>>>>>
>>>>> On Thu, Jul 28, 2022 at 6:07 AM Kentaro Hara 
>>>>> wrote:
>>>>>
>>>>>> Thanks all for the input!
>>>>>>
>>>>>> Dana:
>>>>>>
>>>>>>> This list includes per-file owners, did the script look for 100 CLs
>>>>>>> in those files named by the rule when deciding to remove the person?
>>>>>>
>>>>>>
>>>>>> Thanks for pointing this out! I'll exclude per-file owners from the

Re: [chromium-dev] Re: [blink-dev] Inactive OWNERS cleanup

[Kentaro Hara]

nd found
> <https://chromium-review.googlesource.com/c/chromium/src/+/3750667> (as
> list, Google internal only
> <https://docs.google.com/spreadsheets/d/1BWvj44vJUjSXUHI85fJwX8AgIoYR5SkAm378pp80ljw/edit?resourcekey=0-7pInBE4h65x3c5t6Af1hbA#gid=0>)
> many accounts that no longer exist (or perhaps never did) in OWNERS. It
> probably has different false positives than the proposed set above. Maybe
> the intersection of the two sets would be sensible?
>
> On Thu, 28 Jul 2022 at 07:45, Pavel Feldman  wrote:
>
>> The data in the table seems off, what is considered a "review": is that a
>> "Code Review +1" or is that any review comment?
>> I also have an edge case where I'm mostly interested in several files in
>> a folder where other files are being changed more frequently, should I be
>> optimizing OWNERS to list myself as per-file?
>>
>> On Wednesday, July 27, 2022 at 2:16:47 PM UTC-7 Matt Menke wrote:
>>
>>> Maybe it would make more sense to identify OWNERS who are not active
>>> globally in chrome/, instead of owners not active in a particular
>>> directory?  How common are OWNERS active in Chrome, but high latency only
>>> for specific directories?  I'm asking as someone who was recently inundated
>>> by auto-generated removal CLs, the majority of which did not make sense
>>> (admittedly, I believe it wasn't based on activity).  The tool even seemed
>>> to want to remove all owners from some directories.
>>>
>>> On Wednesday, July 27, 2022 at 5:03:05 PM UTC-4 k...@chromium.org wrote:
>>>
>>>> I echo Dana's concern about removing per-file owners and would like to
>>>> see that policy rethought. Agree with Peter's observations as well.
>>>>
>>>> -Ken
>>>>
>>>>
>>>>
>>>> On Wed, Jul 27, 2022 at 9:12 AM Peter Boström 
>>>> wrote:
>>>>
>>>>> I'm worried that this process excludes/penalizes folks who may be OOO
>>>>> for extended leave (incl long stretches of parental leave, bereavement) 
>>>>> and
>>>>> have that in their Gerrit status. This should not be a source of review
>>>>> latency, if it is Gerrit should better surface that they are OOO.
>>>>>
>>>>> Are any of the inactive owners, who did opt out last time, a source of
>>>>> review latency? I.e. are reviews assigned to them but they don't review
>>>>> them within some SLO window? Otherwise I strongly suggest we let folks
>>>>> decline the OWNERS removal (at other OWNERS' discretion who should 
>>>>> probably
>>>>> review removal CLs).
>>>>>
>>>>> On Wed, Jul 27, 2022 at 8:08 AM  wrote:
>>>>>
>>>> This list includes per-file owners, did the script look for 100 CLs in 
>>>> *those
>>>>>> files* named by the rule when deciding to remove the person?
>>>>>>
>>>>>> On Tue, Jul 26, 2022 at 9:16 PM Kentaro Hara 
>>>>>> wrote:
>>>>>>
>>>>> Hi
>>>>>>>
>>>>>>> As of 2022 July, Chromium has 4531 OWNERS files containing 6850
>>>>>>> names. These include inactive owners, which are one of the sources of 
>>>>>>> slow
>>>>>>> code review latency. One year ago, we cleaned up inactive owners
>>>>>>> <https://groups.google.com/a/chromium.org/g/chromium-dev/c/MpOgk56qKS0/m/HHy7G19oAwAJ>
>>>>>>> and removed ~500 inactive owners. I propose running the clean-up process
>>>>>>> again to keep the OWNERS files updated.
>>>>>>>
>>>>>>> Specifically, a person is identified as an "inactive" owner iff:
>>>>>>>
>>>>>>>-
>>>>>>>
>>>>>>>The person didn't commit or review any CLs in the directory they
>>>>>>>own while there were 100+ CLs that touched the directory in the past 
>>>>>>> 6
>>>>>>>months (as of July 6, 2022).
>>>>>>>
>>>>>>> Last year, I gave the inactive owners an option to flip the decision
>>>>>>> manually to stay as an owner, but for this cycle, I'm planning to remove
>>>>>>> the inactive owners unconditionally. The rationale is 1) if the person 
>>>>>>> made
>>>>

[blink-dev] Inactive OWNERS cleanup

[Kentaro Hara]

Hi

As of 2022 July, Chromium has 4531 OWNERS files containing 6850 names.
These include inactive owners, which are one of the sources of slow code
review latency. One year ago, we cleaned up inactive owners
<https://groups.google.com/a/chromium.org/g/chromium-dev/c/MpOgk56qKS0/m/HHy7G19oAwAJ>
and removed ~500 inactive owners. I propose running the clean-up process
again to keep the OWNERS files updated.

Specifically, a person is identified as an "inactive" owner iff:

   -

   The person didn't commit or review any CLs in the directory they own
   while there were 100+ CLs that touched the directory in the past 6 months
   (as of July 6, 2022).

Last year, I gave the inactive owners an option to flip the decision
manually to stay as an owner, but for this cycle, I'm planning to remove
the inactive owners unconditionally. The rationale is 1) if the person made
no contribution on a very active directory for 6 months, it will be
reasonable to say that the person is inactive, and 2) if there is any
special reason for it and the person needs to stay as an owner, the person
can show evidence that they are meeting the owners expectations
<https://chromium.googlesource.com/chromium/src/+/master/docs/code_reviews.md#expectations-of-owners>
and be readded through the standard OWNERS nomination process.

Specifically, people listed in this spreadsheet
<https://docs.google.com/spreadsheets/d/1gJbXzTaoITvCDmQaqMmGCvfOngrcFtMPmMsGhHgEV_4/edit#gid=0>
are identified as inactive owners and will be removed.

I understand this is a tricky proposal. Having your name on OWNERS is an
award for your previous amazing contributions, and I understand your
feeling about your name being removed. However, I think it's important to
keep the OWNERS files updated so that Chromium developers can find active
owners and improve the code review latency.

If you have any questions / concerns, please let me know. Thanks!
-- 
Kentaro Hara, Tokyo

-- 
You received this message because you are subscribed to the Google Groups 
"blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to blink-dev+unsubscr...@chromium.org.
To view this discussion on the web visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CABg10jyArLjDp0ixPu%2BCSZ9NVrn0M1GwNFiJqiPGRE1f0mrbfQ%40mail.gmail.com.

Re: [blink-dev] PSA: Blink is now using gfx int/float geometry types

[Kentaro Hara]

I know Xianzhu and @Dave Tapuska   had been working
really hard to deprecate the blink-specific geometry types for a long time.
I'm excited to see it's finally complete! Thanks Xianzhu and Dave for all
the efforts :D



On Sat, Jan 15, 2022 at 2:56 PM Xianzhu Wang 
wrote:

> Hi, blink-dev,
>
> As the second part of crbug.com/738465, we have finished migrating blink
> to use gfx int/float geometry types:
>
>- blink::IntRect -> gfx::Rect
>- blink::IntPoint -> gfx::Point (if it's a point) or gfx::Vector2d (if
>it's an offset)
>- blink::IntSize -> gfx::Size (if it's a size) or gfx::Vector2d (if
>it's an offset)
>- blink::FloatRect -> gfx::RectF
>- blink::FloatPoint -> gfx::PointF (if it's a point) or gfx::Vector2dF
>(if it's an offset)
>- blink::FloatSize -> gfx::SizeF (if it's a size) or gfx::Vector2dF
>(if it's an offset)
>- blink::FloatBox -> gfx::BoxF
>- blink::FloatQuad -> gfx::QuadF
>- blink::FloatPoint3D -> gfx::Point3F (if it's a point) or
>gfx::Vector3dF (if it's an offset)
>- blink::IntRectOutsets -> gfx::Outsets or gfx::Insets
>- blink::FloatRectOusets -> gfx::OutsetsF or gfx::Outsets
>
> Most differences between the blink types and gfx types are
> straightforward, but the following are notable:
>
>- gfx::Size, gfx::SizeF, gfx::Rect and gfx::RectF clamp negative
>width/height to zero.
>- All gfx integer geometry types clamp values to integer range. Some
>stored values are clamped to prevent overflow of calculated values. For
>example, gfx::Rect clamps also clamps width to prevent overflow of right
>(x+width).
>
> Cheers,
> Xianzhu
>
> --
> You received this message because you are subscribed to the Google Groups
> "blink-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to blink-dev+unsubscr...@chromium.org.
> To view this discussion on the web visit
> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CADBxricqKD4J%2Bvm_d8bpcD9QX6Ux-3qSctX_YHN-bPU9Fc-zxw%40mail.gmail.com
> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CADBxricqKD4J%2Bvm_d8bpcD9QX6Ux-3qSctX_YHN-bPU9Fc-zxw%40mail.gmail.com?utm_medium=email&utm_source=footer>
> .
>


-- 
Kentaro Hara, Tokyo

-- 
You received this message because you are subscribed to the Google Groups 
"blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to blink-dev+unsubscr...@chromium.org.
To view this discussion on the web visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CABg10jweq5FHcD8LQkaSB2uZ%2BY%3DmLOOujNy1ZGGJ9F69S5i7OQ%40mail.gmail.com.

[blink-dev] Re: Tree is being closed for MiraclePtr Big Rewrite

[Kentaro Hara]

Thank you very much Keishi for driving all the efforts, and @Bartek
Nowierski  @Sergei Glazunov  @Benoit
Lize  @Sébastien Marchand  @Daniel
Cheng  @Takashi Sakamoto  @Yuki Yamada
 for the significant contributions to complete the
weekend Big Rewrite!

I'm truly impressed by your team play. You did a lot of preparations /
simulations in advance. You encountered an unexpected C++ compiler bug
during the Big Rewrite but identified the cause & a workaround very
quickly. Congrats! 🎉🎉🎉




On Sun, Nov 28, 2021 at 9:53 PM Keishi Hattori  wrote:

> Hello chromium community,
>
> We have reopened the tree after successfully applying the MiraclePtr Big
> Rewrite. Thank you for your patience. Let us know if you have any
> questions or see any weirdness.
>
> Cheers,
> MiraclePtr Big Rewrite Team
>
> On Sat, Nov 27, 2021 at 12:01 PM Keishi Hattori 
> wrote:
>
>> Hello chromium community,
>>
>> We are closing the tree shortly in order to do the MiraclePtr Big Rewrite
>> <https://groups.google.com/a/chromium.org/g/chromium-dev/c/vAEeVifyf78/m/SkBUc6PhBAAJ>.
>> If all goes well we shall reopen the tree with everything in 44 hours. We
>> will report back if we encounter difficulties or upon success.
>>
>> Cheers,
>>
>> MiraclePtr Big Rewrite Team
>>
>>

-- 
Kentaro Hara, Tokyo

-- 
You received this message because you are subscribed to the Google Groups 
"blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to blink-dev+unsubscr...@chromium.org.
To view this discussion on the web visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CABg10jzdGvmAuyfO%2BiqiyokEYXgr_uXege2oEfYhbRr4-YqP_g%40mail.gmail.com.

Re: [blink-dev] Questions about WTF_ALLOW_MOVE_INIT_AND_COMPARE_WITH_MEM_FUNCTIONS

[Kentaro Hara]

+1 to migrate to the gfx types without the macro. Thanks for confirming the
performance numbers!



On Fri, Nov 5, 2021 at 10:23 AM Xianzhu Wang 
wrote:

> On Thu, Nov 4, 2021 at 11:38 AM Xianzhu Wang 
> wrote:
>
>> Actually we have only two remaining usages of such macros in blink
>> geometry types:
>> 1. float_size.h
>> <https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/renderer/platform/geometry/float_size.h;drc=134f570f0aff185007cd8a2757f4188567a7df9f;l=240>
>> :
>>   // Allows this class to be stored in a HeapVector.
>>   WTF_ALLOW_CLEAR_UNUSED_SLOTS_WITH_MEM_FUNCTIONS(blink::FloatSize)
>>   This seems unnecessary because FloatSize is not a garbage collected
>> type, and we don't have any usage of Vector in blink.
>> 2. int_rect.h
>> <https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/renderer/platform/geometry/int_rect.h;drc=134f570f0aff185007cd8a2757f4188567a7df9f;l=272>
>> :
>>   WTF_ALLOW_MOVE_INIT_AND_COMPARE_WITH_MEM_FUNCTIONS(blink::IntRect)
>>   We have a lot of Vector usages. Will try perf tests.
>>
>
> Perf tests didn't show an obvious difference with
> WTF_ALLOW_MOVE_INIT_AND_COMPARE_WITH_MEM_FUNCTIONS(blink::IntRect) removed.
> The results actually show progressions of total rendering CPU usage, but
> they are likely to be just noise. See the pinpoint results in
> https://chromium-review.googlesource.com/c/chromium/src/+/3262556 for
> details.
>
> So I'm going forward to migrate blink geometry types to gfx types without
> worrying about WTF_ALLOW_MOVE_INIT_AND_COMPARE_WITH_MEM_FUNCTIONS on
> geometry types.
>
> About std::is_trivial, actually we don't allow particular trivial types to
>> use such macros. For example, in
>> WTF_ALLOW_MOVE_AND_INIT_WITH_MEM_FUNCTIONS, we have:
>>static_assert(!std::is_trivially_default_constructible::value
>> || \
>> !std::is_trivially_move_assignable::value, \
>> "macro not needed"); \
>>
>> Also most of our classes (including all geometry classes) are not
>> trivially default constructible because they do need initialization. We
>> could check if a default constructed object is all zero to see if it can be
>> initialized by memset, but I'm not sure if this is possible at compile time.
>>
>> It seems that we can check std::is_trivially_copyable and/or
>> std::is_trivially_move_assignable for kCan*WithMemcpy
>> and kCanCompareWithMemcmp.
>>
>
> Actually we are already doing this
> <https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/renderer/platform/wtf/vector_traits.h;drc=c31166996f0c14c8d88f2ca2fdd1bbfce0f9f6f0;l=51>
> :)
>
>
>>
>> On Thu, Nov 4, 2021 at 10:39 AM Xianzhu Wang 
>> wrote:
>>
>>> One data point: the CL
>>> <https://chromium-review.googlesource.com/c/chromium/src/+/3252774>
>>> that replaces blink::IntPoint (declared with the macro) with gfx::Point was
>>> landed 2 days ago, and I haven't received any performance bug yet. Perhaps
>>> we don't use Vector in performance critical code.
>>>
>>> Will try std::is_trivial before converting other types.
>>>
>>> On Thu, Nov 4, 2021 at 10:19 AM Daniel Bratell 
>>> wrote:
>>>
>>>> (see inline)
>>>> On 2021-11-03 12:15, Kentaro Hara wrote:
>>>>
>>>> The VectorTraits::kCan{Copy,Move,Fill,Compare}... fields are used
>>>>> for all Vectors though, no? This particular macro doesn't appear to
>>>>> explicitly define/override any Oilpan-related fields AFAICS.
>>>>
>>>>
>>>> You're right -- thanks for pointing it out :)
>>>>
>>>> a) The macros work as a performance optimization for all Vectors. I
>>>> have no data about the performance numbers though.
>>>>
>>>> The traits have a big effect on micro-benchmarks but it's always hard
>>>> to map that to user observable performance.
>>>>
>>>> Furthermore, is it possible to replace the macros with use of standard
>>>> C++ traits such as std::is_trivial
>>>> <http://www.cplusplus.com/reference/type_traits/is_trivial/>? It would
>>>> require auditing current types, and possibly modifying them, but that is
>>>> something that has to be done anyway before a complete type merge between
>>>> Blink and
>>>>
>>>> /Daniel
>>>>
>>>>
>>>> b) Some of the macros are mandatory to make HeapVector work
>>>> cor

Re: [blink-dev] Questions about WTF_ALLOW_MOVE_INIT_AND_COMPARE_WITH_MEM_FUNCTIONS

[Kentaro Hara]

>
> The VectorTraits::kCan{Copy,Move,Fill,Compare}... fields are used for
> all Vectors though, no? This particular macro doesn't appear to
> explicitly define/override any Oilpan-related fields AFAICS.


You're right -- thanks for pointing it out :)

a) The macros work as a performance optimization for all Vectors. I have
no data about the performance numbers though.
b) Some of the macros are mandatory to make HeapVector work correctly
(e.g., see static_assert here
<https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/renderer/platform/heap/collection_support/heap_vector_backing.h;l=81?q=kCanClearUnusedSlotsWithMemset&ss=chromium%2Fchromium%2Fsrc:third_party%2Fblink%2Frenderer%2Fplatform%2F>
).

b) does not apply to the geometry types in question. Regarding a), maybe
can we just measure performance using benchmarks and see if dropping the
macros causes performance regressions? (I hope not.)


On Wed, Nov 3, 2021 at 7:19 PM Fredrik Söderquist  wrote:

> On Wed, Nov 3, 2021 at 12:29 AM Kentaro Hara  wrote:
>
>> The macro matters only for objects stored in HeapVector (i.e. Oilpan).
>> So you don't need to export the macro outside Blink :)
>>
>
> The VectorTraits::kCan{Copy,Move,Fill,Compare}... fields are used for
> all Vectors though, no? This particular macro doesn't appear to
> explicitly define/override any Oilpan-related fields AFAICS.
>
>
> /fs
>
>
>>
>>
>> 2021年11月3日(水) 8:04 Xianzhu Wang :
>>
>>> Hi,
>>>
>>> I'm migrating blink to use gfx geometry types, and noticed
>>> that WTF_ALLOW_MOVE_INIT_AND_COMPARE_WITH_MEM_FUNCTIONS is applied to blink
>>> geometry types. It seems to optimize performance of Vector.
>>>
>>> I have the following questions:
>>>
>>> 1. For a type defined out of blink, how do we force users to include a
>>> header delaring WTF_ALLOW_MOVE_INIT_AND_COMPARE_WITH_MEM_FUNCTIONS(Type)?
>>> I'm thinking of putting it in vector_traits.h
>>> <https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/renderer/platform/wtf/vector_traits.h>,
>>> but I would like to know if there are better ways.
>>>
>>> 2. Do we have data showing the performance difference with and without
>>> WTF_ALLOW_MOVE_INIT_AND_COMPARE_WITH_MEM_FUNCTIONS?
>>>
>>> Thanks,
>>> Xianzhu
>>>
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "blink-dev" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to blink-dev+unsubscr...@chromium.org.
>>> To view this discussion on the web visit
>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CADBxriepZahOVJfzQseAyFfkjUPUgLWovXrKUYH54UGY6K2mEw%40mail.gmail.com
>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CADBxriepZahOVJfzQseAyFfkjUPUgLWovXrKUYH54UGY6K2mEw%40mail.gmail.com?utm_medium=email&utm_source=footer>
>>> .
>>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "blink-dev" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to blink-dev+unsubscr...@chromium.org.
>> To view this discussion on the web visit
>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CABg10jxn-cipEGf%2BU04WVa3UNqLmqmFcX55dWCPy_KK6huAe3A%40mail.gmail.com
>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CABg10jxn-cipEGf%2BU04WVa3UNqLmqmFcX55dWCPy_KK6huAe3A%40mail.gmail.com?utm_medium=email&utm_source=footer>
>> .
>>
>

-- 
Kentaro Hara, Tokyo

-- 
You received this message because you are subscribed to the Google Groups 
"blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to blink-dev+unsubscr...@chromium.org.
To view this discussion on the web visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CABg10jxmhADNpdOCAnq_VbH-R%2BVbhJc%3DvS2CAW4LQv10OukU6w%40mail.gmail.com.

Re: [blink-dev] Questions about WTF_ALLOW_MOVE_INIT_AND_COMPARE_WITH_MEM_FUNCTIONS

[Kentaro Hara]

The macro matters only for objects stored in HeapVector (i.e. Oilpan).
So you don't need to export the macro outside Blink :)


2021年11月3日(水) 8:04 Xianzhu Wang :

> Hi,
>
> I'm migrating blink to use gfx geometry types, and noticed
> that WTF_ALLOW_MOVE_INIT_AND_COMPARE_WITH_MEM_FUNCTIONS is applied to blink
> geometry types. It seems to optimize performance of Vector.
>
> I have the following questions:
>
> 1. For a type defined out of blink, how do we force users to include a
> header delaring WTF_ALLOW_MOVE_INIT_AND_COMPARE_WITH_MEM_FUNCTIONS(Type)?
> I'm thinking of putting it in vector_traits.h
> ,
> but I would like to know if there are better ways.
>
> 2. Do we have data showing the performance difference with and without
> WTF_ALLOW_MOVE_INIT_AND_COMPARE_WITH_MEM_FUNCTIONS?
>
> Thanks,
> Xianzhu
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "blink-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to blink-dev+unsubscr...@chromium.org.
> To view this discussion on the web visit
> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CADBxriepZahOVJfzQseAyFfkjUPUgLWovXrKUYH54UGY6K2mEw%40mail.gmail.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to blink-dev+unsubscr...@chromium.org.
To view this discussion on the web visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CABg10jxn-cipEGf%2BU04WVa3UNqLmqmFcX55dWCPy_KK6huAe3A%40mail.gmail.com.

[blink-dev] Re: Call for Lightning Talks at BlinkOn15!

[Kentaro Hara]

The deadline of the lightning talk application is *Oct 21 (this Thursday)*.
First come, first served. For now it's fine to add "TBD" to your talk title
and slide. If you're interested, please sign up on the sheet before closing
this email :)

Thanks!



On Tue, Oct 5, 2021 at 10:52 AM Kentaro Hara  wrote:

> Hi,
>
> I'm happy to announce that lightning talks are coming back to BlinkOn 15!
> This is a great opportunity to present your projects without having a
> formal session :)
>
> The rule is simple:
>
>
>-
>
>Each talk should be kept to 3 mins.
>-
>
>Add your name to this sheet
>
> <https://docs.google.com/spreadsheets/d/1FzxhGtmfaEP_yO8ePmWoYuvFS0qk44hQA5Mui06E9Rk/edit#gid=0>
>before Oct 21.
>-
>
>All talks must be recorded in a video by Nov 3. The instructions will
>be shared with the speakers at a later date..
>-
>
>You can talk about anything about Blink, any crazy ideas are welcome!
>
>
> Let's make the virtual BlinkOn more exciting with the lightning talk
> sessions :)
>
> Kentaro Hara on behalf of the BlinkOn planning team
>
> --
> Kentaro Hara, Tokyo
>


-- 
Kentaro Hara, Tokyo

-- 
You received this message because you are subscribed to the Google Groups 
"blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to blink-dev+unsubscr...@chromium.org.
To view this discussion on the web visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CABg10jx7fNynjUEcPNu3WaRrzPRFXFJFUg_akcdY5SO086yLYw%40mail.gmail.com.

[blink-dev] Call for Lightning Talks at BlinkOn15!

[Kentaro Hara]

Hi,

I'm happy to announce that lightning talks are coming back to BlinkOn 15!
This is a great opportunity to present your projects without having a
formal session :)

The rule is simple:


   -

   Each talk should be kept to 3 mins.
   -

   Add your name to this sheet
   
<https://docs.google.com/spreadsheets/d/1FzxhGtmfaEP_yO8ePmWoYuvFS0qk44hQA5Mui06E9Rk/edit#gid=0>
   before Oct 21.
   -

   All talks must be recorded in a video by Nov 3. The instructions will be
   shared with the speakers at a later date..
   -

   You can talk about anything about Blink, any crazy ideas are welcome!


Let's make the virtual BlinkOn more exciting with the lightning talk
sessions :)

Kentaro Hara on behalf of the BlinkOn planning team

-- 
Kentaro Hara, Tokyo

-- 
You received this message because you are subscribed to the Google Groups 
"blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to blink-dev+unsubscr...@chromium.org.
To view this discussion on the web visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CABg10jy41jFHnp2_7EReu4aOvgsLE4VU7KrBhvBwyL33wxPtCg%40mail.gmail.com.

Re: [blink-dev] Bindings: Subclassing DOMException

[Kentaro Hara]

@Yuki Shiino 

On Mon, Aug 23, 2021 at 5:22 PM Adam Rice  wrote:

> I need to create a subclass of DOMException (WebTransportError
> <https://w3c.github.io/webtransport/#web-transport-error-interface>). I
> would like to make sure the stack is initialised correctly, but
> V8ThrowDOMException::CreateOrEmpty()
> <https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/renderer/bindings/core/v8/v8_throw_dom_exception.h;l=30?q=V8ThrowDOMException::CreateOrEmpty>
> is not reusable and looks really complicated.
>
> Is there a good solution?
>
> --
> You received this message because you are subscribed to the Google Groups
> "blink-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to blink-dev+unsubscr...@chromium.org.
> To view this discussion on the web visit
> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAC_ixdxhHpxjAjqDgq%2BD7HNx3_ZixfYzUTCT215mdHiUJtZ17A%40mail.gmail.com
> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAC_ixdxhHpxjAjqDgq%2BD7HNx3_ZixfYzUTCT215mdHiUJtZ17A%40mail.gmail.com?utm_medium=email&utm_source=footer>
> .
>


-- 
Kentaro Hara, Tokyo

-- 
You received this message because you are subscribed to the Google Groups 
"blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to blink-dev+unsubscr...@chromium.org.
To view this discussion on the web visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CABg10jzxFNFFgezErSxtRhTOE_R1UeQ2uk%3DmrByo1jLvA325GA%40mail.gmail.com.