Re: RFR: 8332313: Update code review guidelines [v2]

2024-05-18 Thread Nir Lisker
On Sat, 18 May 2024 14:24:49 GMT, Kevin Rushforth  wrote:

> Maybe it's worth changing "adds any new" to "adds, removes, or modifies any"?

This looks like a good idea.

-

PR Review Comment: https://git.openjdk.org/jfx/pull/1455#discussion_r1605798488


Re: RFR: 8332313: Update code review guidelines [v2]

2024-05-18 Thread Kevin Rushforth
On Fri, 17 May 2024 15:02:14 GMT, Nir Lisker  wrote:

>> Kevin Rushforth has updated the pull request with a new target base due to a 
>> merge or a rebase. The incremental webrev excludes the unrelated changes 
>> brought in by the merge/rebase. The pull request contains 20 additional 
>> commits since the last revision:
>> 
>>  - Wait for re-review if you've pushed a change addressing a substantive 
>> comment
>>  - Typo + remove sentence that invites reformatting PRs
>>  - Wording changes, added example of API addition
>>  - Formatting
>>  - Add item about checking the target branch
>>  - Remove trailing period from previous
>>  - Minor changes regarding syncing from upstream master
>>  - Clarify that GHA tests might fail for a reason unrelated to the PR
>>  - Fix typo
>>
>>"but It" --> "but it"
>>  - Remove bullet about checking the commit message (Skara already checks)
>>  - ... and 10 more: https://git.openjdk.org/jfx/compare/1a4c0fd4...9cf7f920
>
> README-code-reviews.md line 69:
> 
>> 67: * Carefully consider the risk of regression
>> 68: * Carefully consider any compatibility concerns
>> 69: * Check whether it adds any new public or protected API, even implicitly 
>> (such as a public method that overrides a protected method, or a class that 
>> is moved from a non-exported to an exported package); if it does, indicate 
>> that it needs a CSR
> 
> I think that if it looks like an oversight (the author forgot about the 
> default constructor), it's better to indicate that than to indicate that the 
> PR needs a CSR. Maybe something like:
> "if it does and it doesn't look like an oversight, indicate that it needs a 
> CSR"

We have by now cleaned up our public API to avoid classes with an implicit 
no-arg constructor, so the only way this situation could arise in the future is 
if someone adds a new public class, which needs a CSR anyway.

I guess it could also happen if someone proposed to delete the no-arg 
constructor, but we don't allow deleting of non-terminally-deprecated API 
anyway. Maybe it's worth changing "adds any new" to "adds, removes, or modifies 
any"?

Somewhat related, these guidelines don't address what to look for when 
reviewing new API; perhaps a follow-on issue.

-

PR Review Comment: https://git.openjdk.org/jfx/pull/1455#discussion_r1605797980


Re: RFR: 8322619: Parts of SG no longer update during rendering - overlapping - culling - dirty [v5]

2024-05-18 Thread Kevin Rushforth
On Fri, 17 May 2024 12:36:22 GMT, Florian Kirmaier  
wrote:

> Sorry for creating the CSR, it was an accident.

No problem.

> Now that Eduard has both created an alternative solution, but also has 
> reviewed that this solution is correct, and provided an unit-test - I think 
> this (or the other) PR is ready to move forwards.
> 
> @kevinrushforth What do you think?

Yes, I've asked @arapte to be the primary reviewer on this. I'll leave it to 
his judgment as to which of the two approaches to take forward.

-

PR Comment: https://git.openjdk.org/jfx/pull/1310#issuecomment-2118837579


Re: RFR: 8322619: Parts of SG no longer update during rendering - overlapping - culling - dirty

2024-05-18 Thread Kevin Rushforth
On Fri, 17 May 2024 13:46:12 GMT, eduardsdv  wrote:

> > I'm only wondering if the code in `paintImpl` should always clear the dirty 
> > bits even if an exception occurs during painting, to harden it against 
> > potential bugs and not end up trying to repaint again and again likely 
> > getting the same exception again and again.
> 
> Hm, that can indeed happen. On the other hand, if the dirty flag is reset 
> even in the case of an exception, parts of the UI may not be updated for a 
> long time until a node in that area receives a change. The question is which 
> of these two options is the least harmful.
> 
> I'm fine with each of them. What do the others think?

I'd probably lean towards addressing this in a follow-up issue, if there turns 
out to be a need.

@arapte can you look at this when you review it?

-

PR Comment: https://git.openjdk.org/jfx/pull/1451#issuecomment-2118837167