@Sergey Sharybin (sergey) might want to check on this?

ASAN output is P858

track->markers is garbled.
Will run through ASAN next

Just run a test with the "Default" Color Management. The fps was 11 to 13 fps. So the performance is better, but I don't think this is the main issue here.

This sounds very much like an issue with colormanagement. In 2.80 the default view transform is Filmic. In order to display movie clips correctly the correct mapping has to be applied first. This happens during playback. So once the clip has been played back once, the movie was "converted" internally to the correct view transform. That's why playback is realtime the second time you play it.
You can also set View Transform in Color Management panel from "Filmic" to "Default". That should give you better playback performance right from the first play of the movie.
(Sidenote: "Default" is really not an adequate term anymore, since it isn't even the default setting! :)

I have tested this with a cache setting of 1024 MB. It prefetches a video, could not see any GUI freezings and the progress bar updates.
But the frame rate is low: around 4 to 9 fps. (I see this in a 3d view port in the left top corner of a camera view).
If I play the video (play button, not prefetching) the frame rate is also 4 to 9 fps. But the second time I play it, the part that was "played" plays now with 24 fps.

Just as info for others. To reproduce it in the file, you just have to click "Constraint to F-Curve" in the constraint now.

Here is it the blend file:

Please provide some .blend file that allows us to easily reproduce the issue.

@Sebastian Koenig (sebastian_k), did i get it correct:

My colleague just tested this on Windows10 with the most recent Blender 2.80 build.
While it does prefetch the footage, it does act a bit weird. The interface seems to freeze until the prefetching is done. Unlike in your case however the footage is in memory after prefetching is finished.
Even though the GUI is a bit unresponsive, we could still press the little X in the prefetching progress bar to cancel it. It works pretty much the same as on my Linux system. Our systems are quite good though (32GB, Hexacore). 4GB of system memory is far from ideal for motion tracking, so poor system performance might play a role in your case. Still, I can't really see a bug here.
However, responsiveness when caching movie files could definitely be improved. When prefetching image sequences the interface stays fully repsonsive here, and the way the progress bar is reporting the prefetching progress is more realtime and repsonive as well.
When 2.8 is more stable and there is a bit more time for polishing this might be something to look at, @Sergey Sharybin (sergey)?

That would be fine, although I use Detect Features more than I use the Track Setting as Default or Copy Track Settings.

Ah, good one. Maybe instead of Detect Features? This is not used so often...

This is very nice, seems to be intuitive.

Interesting. Would be nice if some other windows user could test this. At the very least I'll have my colleagues in the office test this on monday.

Ram 4096 MB. Set the value to 3072 MB (good thinking, btw). But still the same issue.

How much RAM do you have, and what's set in your User Preferences, in System>General>Memory Cache Limit? If you prefetch and watch your System's memory consumption, is your RAM filling up or not?

As described above I use Windows 7. It freezes for a while, then the GUI is responsive again. But the prefetch of the footage didn't happen at all.

I don't see a bug here. It's true, Blender does become unresponsive for a moment, but that's just due to the prefetching of the movie file. Prefetching image sequences works smoother. At least on my system (Linux64bit) I cannot see a difference in prefetching between 2.80 and 2.79.

I agree with you for sure that Blender's accuracy is spectacular. :)

@Sean Kennedy (hype) You have probably tracked in way more programs than me, but at least in the handful of tracking programs I tried none of them had the same approach to super accurate supervised tracking like we have eihter. I think in Blender the single marker plays a more important role by itself than elsewhere, so I think it's fine if UI reflects that.

I'm excited to see these tools in the topbar to see how it really feels in action.

I am not sure about merging the track settings to just one panel. It would be a regression to 2.79, where we have those settings separated.

Would it be possible to only have one set of Track Settings? Whatever it is set to when you create a new track, that's what the new track uses. If you have a track selected, those controls then apply to that selected track. It's confusing having two, and this would streamline it quite a bit.

This sounds right to me.

This got fixed by rB9b8d479e414.

I have changed some of the shortcuts.
The Alt key is now being avoided, because on a Mac it is not as comfortable to reach as the shift-key.
So:
Tracking Pie: 'E'
Setup Marker: 'Shift + E'
Setup Display: 'Shift + D'
Setup Tracking Scene: 'Shift + W'
Solve: 'Shift + S'
I find these very comfortable to reach and execute.
Compared to the clip editor hotkeys in 2.79 we would sacrifice Shift+D, which was used for the 'Disable Marker' Hotkey.
However, that operator is in the Tracking Pies at the bottom, very easy to reach.
And the 'Show Disabled Markers' toggle is now at the bottom of the Setup Display Pie, so in the same position, hence very easy to remember.
Following that logic I think we can also remove the hotkey Alt+D, currently used for the "Show Disabled Markers" toggle.
And I would vote for having the tracking pies enabled by default.

Thanks a lot for the feedback!
I agree about the lacking feedback for a toggle in a pie menu possibly being an issue. However, I would like to keep most of them because it makes the workflow so much faster. And they still can be used in a gesture style interaction, contrary to some other pie menues from the community, where there are multiple entries pre pie-slot, something I consider opposite to the idea behind our pie menu implementation. But I'll have a look again and see if some can be replaced.
About hotkeys, well, the left side is pretty crowded. Q, W, A, S, R, D, X, C are all taken. I find combinations of Shift and E, W, S still very easy and comfortable to execute with the left hand. I was about to say the same about Alt+E as well, but I am typing this reply on my macbook, and there the Alt key is in a less comfy place. So I'll have a look at the keys again. :)

This seems generally ok I think.

...in particular, I do not think that an error message is a good solution for a problem. I would better disable that button (or hide it) in case Cycles is not used. What is still missing, I think, is a button that simply put the solver constraint on the camera (without anything else related to adding objects to the scene I mean).

I do not think it can be considered "resolved": the commit considered as the Fix, as far as I understand, works only with Cycles, and I (and I think a lot of people like me) do not understand how to switch the Motion Tracker to Cycles (switching it in the render tab does not work).

@Dalai Felinto (dfelinto) I am wondering if it even makes sense to have an EEVEE setup at this point. As far as I can see EEVEE does not have something like a shadow catcher, nor can collections ins view_layers be set to holdout, which is both kind of important for a working setup. So I would first make it use Cycles.

I have managed to make the Setup_Tracking_Scene operator work without errors by disabling the old BI and layer stuff, now I am trying to make the renderlayer setup work again.
However, it seems as if there are some python bindings missing still.
To make the setup work I am planning to have 2 Viewlayers, Background and Foreground (as was already implemented in the new script), with two collections, "background" and "foreground". In the Foreground viewlayer, the background collection will be set to "holdout", in the Background view_layer the foreground collection will be set to indirect only.
I can make the setup work with the outliner View_Layer menu, however I could not find a way to do that via python. Something like bpy.context.scene.view_layers["Background"].collections["foreground"].holdout = True
That or at least something similar does not seem to exist yet.
Or if it does, maybe someone can give me a hint?

I will have a look

I will have a look. Maybe first just kick out all the old stuff so that at least the basic setup of constraints and background images work. Speaking of which, the whole camera background image stuff doesnt seem to work all that great yet. Footage is always drawn in front of objects, no matter the front/back setting in camera background images. Also the colors are completely off in solid mode.

how about an option to make a simple setup using a shadow catcher plane and just one render layer..? that is often enough to have a working scene

@Sebastian Koenig (sebastian_k) maybe this is something you could help with?