Right @Sun Kim (persun) :)
Bisect points to - rB19b63b932d2b: Fix transform gizmo not updating according to state
@Germano Cavalcante (mano-wii) ^

First of all, thank you for adding all these quality of life updates!
I don't know how much this can create conflict with your addition of size/radius gizmos to lights, but as a user I always found confusing that scaling the lights in the 3D viewport doesn't update the size parameter in the properties, while viceversa doing it in the properties does. If we scale with both methods, the size parameter doesn't reflect anymore the actual size of the light.

In D17167#469226, @Brecht Van Lommel (brecht) wrote:

This is not great but if there is little hope of this getting fixed in the driver soon it seems better.

Will close as resolved then

Hi, thanks for the report, but the issue reported here is a request for modified/improved behavior and not a bug in current behavior. Closing as this bug tracker is only for bugs and errors.
For user requests and feedback, please use other channels: https://wiki.blender.org/wiki/Communication/Contact#User_Feedback_and_Requests
For more information on why this isn't considered a bug, visit: https://wiki.blender.org/wiki/Reference/Not_a_bug

Hi, thanks for the report. Could you share file in which this occurs? or Does this happen in blender-studio file itself?

The blue works very well! But I think it's unnecessary that the overlay is more opaque when using face selection.
Ideally the color should stay the same across all three selection modes.

Hi, thanks for the report. This looks same as in T98348. There is a workaround mentioned below in the discussion. See if that helps.
Please also check whether this happen due to overclocking the GPU.

Hi, thanks for the report. Could you test again with updated GPU drivers?: https://docs.blender.org/manual/en/dev/troubleshooting/gpu/linux/amd.html

Hey Sergey,

This is a GPU with a lot of threads, and every threads needs its working state. There is some dependency of the size of the state from the features used in the scene, but is it not linear from the scene complexity perspective.

@Antonio Vazquez (antoniov) I'm assigning you to the task I could not find a proper solution for.. so it does not get lost.

Can confirm this on latest master.

After a little bit more test:

The hypothetical worst-case this would avoid is building and throwing away the object hash on frame-change (for e.g.),

• Fix comment typo

Thanks for checking on the dependsOnNormal.

I would like to mention that T100369 is related to the legacy particle system, rather than the new one.

Thanks for your instruction.
blf.dimensions(0, "Hy|") works good without any lagging.
I think this workaround is enough for my use case.

Narrows it down to a having first appeared in the 3.3 release.

attached the crash report

In D9415#469370, @Germano Cavalcante (mano-wii) wrote:

• Rebase on master

Formatting.

I think this would be nice to have. We'll probably only have more places where we need to store a single generic value in the future. It would have been helpful for D16816 anyway.

• Rebase
• Move reflection/refraction Fresnel distinction into microfacet_fresnel. This will be needed for some more advanced Fresnel models, and removes duplication.

https://builder.blender.org/admin/#/builders/136/builds/459