Can confirm crash in 057fe2c8d0c3 but not in 5854438265c5 (nov 21). I assume this has been resolved.
If issues persist we can reopen.

@Volodymyr Shaparenko (Vova12zx) Thanks for file, I don't use masking a lot so I didn't see immediately what the problem was.

Edge crease is currently implemented as transform operator, so it handles input in similar way. As far as I can see, this is not a bug.

In T82698#1059727, @Volodymyr Shaparenko (Vova12zx) wrote:

Thanks for the answer, Richard!

1. I have watched the "transition.blend" file -> Your method works! :)
2. I have pressed these "Ctrl+R" keys -> This method doesn't work! :(

@Gerard Taulats Braos (Tabra) Thanks for report. Maintainer of power sequencer is @Nathan Lovato (gdquest).

Thanks for info, so the script doesn't play any role here - you need 2 bones and Axle_E to demonstrate this.
I had to google if this is known issue and apparently it is caused by Track To constraint. I guess this would be similar issue as T56176

In D9601#239136, @Sergey Sharybin (sergey) wrote:

This is quite tricky code, in a sense that it doesn't bring immediate "yeah, go for it" thoughts. Can you give some more context over what is the problem you're solving with the change? That would help understanding how/if the proposed change can be accepted.

Thanks for videos,

In T82271#1059029, @Sergei Sobolev (Hrofti) wrote:

I do not know what to say. I use the latest stable version 2.91 If it has fixed in the second version it is good. Thank you a lot.

2.91 is still beta. I guess you ment 2.90.1?

It is very unintuitive and impractical the way it is now. I have no thought anout strobe really.

In T82628#1057727, @Into (intoo) wrote:

Sorry for the delay. I am not very experienced in this kind of task, so I don't really know what information is relevant. What kind of information should I post here?

• Fix typo

This is how this feature was designed. I want to change it once all logic is at one place (so T77580 would be done)
Setting known issue for now.

• Remove scale to fit from preprocessing stage
• Set scale when strip is added
• Update operator with changed design
• Add Fit Method property to image_strip_add and movie_strip_add operators
• Add versioning code
• Implement tool settings for sequencer, add fit method to tool settings

Forgot to mention this is broken at least since 2.80, so probably not for bcon4?

Oops managed to mangle diff link in commit.
Closed by 8ec6b34b8eb2

I got an idea to store seqbase pointer is Sequence, but the issue here is different. I just forgot where I left this patch.
Sorry for noise.

• Rebase

In D9414#238162, @Sergey Sharybin (sergey) wrote:

Wouldn't it be better if we scaled to exact size we need? Then we can skip one scaling step alltogether. Even if we had to use different approach for images.

The exact size you wouldn't really know in advance, as it will depend on settings and other factors. You don't want to re-implement that on the IO level.

Well if you can scale to arbitrary size, in this patricular case you know exact size.
But I can see why this is not what you meant in design description, I am not going to argue this here, I can present you performance of each implementation and then we can decide.

In D9414#238121, @Sergey Sharybin (sergey) wrote:

In this context slightly different approach will be more efficient:

• Only scale down video if it's too large. For example, if video is 360p, there is no need to scale it up or down.
• Only scale based on power of two.

• Update pfjob fields before running update functions

• Use operator to switch scale presets

Ok I think I misunderstood this, will update patch with new operator and add more scale to X features proposed by @Peter Fog (tintwotin) while I am at it.

The bmain entry is not necessary for initialization, but it must be updated. By initialization I mean creating entries only once per job lifetime. Start sequence is initialize if necessary -> update -> run thread

In T82755#1055983, @Sergey Sharybin (sergey) wrote:

The description of operator seems fine to me, aligned with what we've briefly talked about with Francesco here.

The option in the transform panel I don't think it should exist. It introduces secondary setting which defines resolution of strip. For the ease of code and mental model, I'd say the strip scale is the source of truth. For the convenience purposes we might add a button/easy-to-access-menu next to the scale slider, and make that to run an operator.

In T82755#1055958, @Peter Fog (tintwotin) wrote:

@Richard Antalik (ISS) I think your Scale to Fit is called 'Scale to Fill'(in the first video), whereas your Clear All is Scale to Fit.

No, it's scale to fit, but there is already some scale (see properties). I guess I wanted to demonstrate that this property is unchanged, but in the end it was only confusing. Sorry.

My proposal is:
Add Scale To Fit checkbox to transform panel. It would either scale image to fit preview(default) or render at original size. See demo here:

This should resolve following requirements:

Reset scale so that the strip fully fills the "canvas" (similar of default behavior of VSE in Blender 2.91)
Reset scale to make strip to have same size in the scene pixels as the source (similar to behavior of VSE in Blender 2.91 when you enable Crop option)

@Evan Wilson (EAW) Thanks, I have noticed that it changes the radius, but I didn't know this affects bevel. I think this is best described by T34533 so I will merge this.

• Use PIL_check_seconds_timer() for cost calcuation. Using clock() was too imprecise.

In rB01db805a82129a27b1408d62417c40b0717228dc#286929, @Campbell Barton (campbellbarton) wrote:

Reminder to reference the diff in the commit message: Ref D9495.

https://wiki.blender.org/wiki/Style_Guide/Commit_Messages#Code_Review

Closed by rB01db805a8212

Sorry I must have missed notification on this report.

No activity for more than a week. As per the tracker policy we assume the issue is gone and can be closed.

@Julian Eisel (Severin) Technically this is feature request, but I have confirmed this because this is very reasonable request and good feature to have.
I could have made that clear as well.

This really seems to be GPU related bug, and it may be resolved in future driver versions.
Unfortunately nvidia doesn't have bugtracker so this may take long time to be fixed.

This may be (likely) caused by bug in GPU driver. In such case we can't really do anything about that unless there is workaround.

No activity for more than a week. As per the tracker policy we assume the issue is gone and can be closed.

No activity for more than a week. As per the tracker policy we assume the issue is gone and can be closed.

No activity for more than a week. As per the tracker policy we assume the issue is gone and can be closed.

No activity for more than a week. As per the tracker policy we assume the issue is gone and can be closed.

@Peter Fog (tintwotin) any update here? I got hold of some intel machine (HD graphics 500) and I haven't seen this problem in latest 2.92 build.

Indeed only haswell and higher are supprted. Closing.

I assume this is same issue as T74918, so will merge.

No activity for more than a week. As per the tracker policy we assume the issue is gone and can be closed.

No activity for more than a week. As per the tracker policy we assume the issue is gone and can be closed.

Since this is already covered by existing TODO, I will close this report. Thanks for reporting though.

Thanks for the report. This GPU is below the minimum requirements for Blender, so there is no longer support for it. https://www.blender.org/download/requirements/

Can you upload example file before step which caused vertices to dissapear?

I couldn't reproduce this problem with my account.

Can't find reason why this happens but it looks it should not happen.

I can't seem to be able to reproduce case 1, please add steps to reproduce
I don't use masks really, so I would appreciate steps here as well.

Please upload clips for testing.

Thanks for update, closing.

Yes, this is same problem as in T80424, just different render pipeline. Forgot to check openGL render.

Thanks for update, closing.

I found T75308 describing same problem, but unfortunately without solution.

Please add as much relevant information as you can. So at least we know this isn't same issue, but unfortunately I can't tell what the problem is here.

Thanks for update, can confirm working - closing.

Usually 2.7x version is very safe to run on various hardware configurations without problem.