You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
When computing derived markers, we turn these markers from instant markers into interval markers.
In the marker tooltip, we have custom code to render the image and the window size.
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:
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.
Add a marker field format called screenshot-data-url, maybe with an extra sizeFieldForAspectRatio: string annotation, for the data URL field.
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.
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.
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:
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:
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.screenshot-data-url
, maybe with an extrasizeFieldForAspectRatio: string
annotation, for the data URL field.┆Issue is synchronized with this Jira Task
The text was updated successfully, but these errors were encountered: