Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Make CompositorScreenshot markers schema-based #5303

Open
mstange opened this issue Jan 10, 2025 · 0 comments
Open

Make CompositorScreenshot markers schema-based #5303

mstange opened this issue Jan 10, 2025 · 0 comments
Labels
markers Anything to do with marker data structures, marker chart, or the marker table

Comments

@mstange
Copy link
Contributor

mstange commented Jan 10, 2025

Screenshot markers are currently handled in a custom way, based on marker.data.type === 'CompositorScreenshot'.

These markers don't have a schema. We expect the presence of certain fields (windowID, url, windowWidth, windowHeight) based on the type and the name.

We have custom code in three places:

  1. When computing derived markers, we turn these markers from instant markers into interval markers.
  2. In the marker tooltip, we have custom code to render the image and the window size.
  3. Screenshot tracks are created based on these markers.

For #5302 we'll have to add a schema for these markers which declares all fields.
And it might make sense to simplify marker derivation at the same time, if we have to add an upgrader for these markers anyway.


I suggest the following:

  1. Add a marker field format called screenshot-size, expecting a value of type { width: number, height: number }, so that the window size is displayed as a single field in the tooltip.
  2. Add a marker field format called screenshot-data-url, maybe with an extra sizeFieldForAspectRatio: string annotation, for the data URL field.
  3. To simplify computing derived markers, we should make it so that these markers are start + end markers in the profile, instead of instant markers. We can include the windowID in the marker name, so that the usual name-based matching of start/end markers works for these markers.
  4. Add an upgrader for the processed format which performs the migration, and add code to profile processing which does the same. Then we can separately change the gecko format and remove this new profile processing code, at our own pace.

┆Issue is synchronized with this Jira Task

@canova canova added the markers Anything to do with marker data structures, marker chart, or the marker table label Jan 20, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
markers Anything to do with marker data structures, marker chart, or the marker table
Projects
None yet
Development

No branches or pull requests

2 participants