gfx::Color is currently misused in many places. The DrawTargets expect
the color space to be in device space, e.g. what we are actually going
to draw using. Everything sitting above generally deals with sRGB, as
specified in CSS. Sometimes we missed the conversion from sRGB to device
space when issuing draw calls, and similarly sometimes we converted the
color to device space twice.
This patch splits the type in two. sRGBColor and DeviceColor now
represent sRGB and device color spaces respectively. DrawTarget only
accepts DeviceColor, and one can get a DeviceColor from an sRGBColor via
the ToDeviceColor helper API. The reftests now pass with color
management enabled for everything (e.g. CSS) instead of just tagged
raster images.
There will be a follow up patch to enable color management everywhere by
default on all supported platforms.
Differential Revision: https://phabricator.services.mozilla.com/D64771
This patch adds a notion of "fully transparent" image in the resource cache.
These are not uploaded in the texture cache and image requests return the
necessary information to allow the frame building code to skip emitting
primitives accordingly.
Differential Revision: https://phabricator.services.mozilla.com/D47878
This removes a lot of old cruft in thebes to instantiate Cairo scaled fonts.
Instead, we only instantiate the Cairo scaled font inside Moz2D when we actually
need it for DrawTargetCairo. This thus gets rid of the duplicated code we had
inside both Moz2D and thebes to deal with Cairo scaled fonts.
Differential Revision: https://phabricator.services.mozilla.com/D47297
This requires replacing inclusions of it with inclusions of more specific prefs
files.
The exception is that StaticPrefsAll.h, which is equivalent to StaticPrefs.h,
and is used in `Codegen.py` because doing something smarter is tricky and
suitable for a follow-up. As a result, any change to StaticPrefList.yaml will
still trigger recompilation of all the generated DOM bindings files, but that's
still a big improvement over trigger recompilation of every file that uses
static prefs.
Most of the changes in this commit are very boring. The only changes that are
not boring are modules/libpref/*, Codegen.py, and ServoBindings.toml.
Differential Revision: https://phabricator.services.mozilla.com/D39138
This is a follow up to bug 1564655. It removes the offset from ToDeviceSpace
and thus moves item rects into absolute space which is now the same coordinate
space as the recordings are in.
We also adjust item bounds for fallback blobs.
Some additional changes that need happen to:
1. In Moz2DImageRenderer we can reunify the origin because the recording and
the recording metadata return to using the same coordinate space.
2. The calls to PushLayer can return to using the item bounds
which are now in the same coordinate space.
3. This dirty rect which remains in images space is adjusted during merging.
Differential Revision: https://phabricator.services.mozilla.com/D38015
Currently items are painted with a context that has a transform of
-mLayerBounds.TopLeft(). This means that if TopLeft() changes the commands
will be in the wrong place because the -TopLeft() offset is baked into the
recording.
I don't think we've ever needed to support painting without this transformed
baked in so there were some infrastructure changes that needed to be made to
make this possible. Most of the problems come from the use of
gfxContext::GetClipExtents which expose the bounds of the underlying surface.
The biggest of these was fixed by the CreateClippedDrawTarget rewrite. The rest
should be handled by ensuring that the DrawTarget has bounds that are at least
as big as the union of the individual item bounds. i.e. GetClipExtents should
never intersect with bounds of the item.
This change has a couple of parts:
1. Store mLayerBounds.TopLeft() in the recording so that it will be subtracted
during replay
2. Use mLayerBounds as the Rect of the RecordingDrawTarget
3. Don't include mLayerBounds.TopLeft() in the transform during recording.
4. Adjust the dirty rect by recordingOrigin before we use it as a clip so that
it stays in the right place.
5. In PaintContainerItem the bounds parameter of PushLayer is in device space
so we need to account for the shift in the location of device space in the
DrawTargetRecording.
Differential Revision: https://phabricator.services.mozilla.com/D37513
I suspect we may change things more in the future as we blob's size
just be the visible rect but this is an incremental step in the right
direction.
It also includes some changes to make sure that we always update our
tiles appropriately.
Differential Revision: https://phabricator.services.mozilla.com/D37079
This will let us do the subtraction of the recording origin during
playback instead of during recording.
It will also let us merge recordings that have different origins.
Differential Revision: https://phabricator.services.mozilla.com/D37561
This removes duplication and makes it a bit safer by using ConvertFromBytes to
do an unaligned read of the indexOffset.
Also, inner classes can't have template methods. Who knew.
Differential Revision: https://phabricator.services.mozilla.com/D37870
This will let us do the subtraction of the recording origin during
playback instead of during recording.
It will also let us merge recordings that have different origins.
Differential Revision: https://phabricator.services.mozilla.com/D37561
I suspect we may change things more in the future as we blob's size
just be the visible rect but this is an incremental step in the right
direction.
It also includes some changes to make sure that we always update our
tiles appropriately.
Differential Revision: https://phabricator.services.mozilla.com/D37079
This will let us do the subtraction of the recording origin during
playback instead of during recording.
It will also let us merge recordings that have different origins.
Differential Revision: https://phabricator.services.mozilla.com/D37561
I suspect we may change things more in the future as we blob's size
just be the visible rect but this is an incremental step in the right
direction.
It also includes some changes to make sure that we always update our
tiles appropriately.
Differential Revision: https://phabricator.services.mozilla.com/D37079
gfxPrefs Live preferences are almost identical to StaticPrefs.
We leave aside for now those that set a custom change callback as this feature isn't yet supported in StaticPrefs.
Differential Revision: https://phabricator.services.mozilla.com/D31256
gfxPrefs Live preferences are almost identical to StaticPrefs.
We leave aside for now those that set a custom change callback as this feature isn't yet supported in StaticPrefs.
Differential Revision: https://phabricator.services.mozilla.com/D31256
gfxPrefs Live preferences are almost identical to StaticPrefs.
We leave aside for now those that set a custom change callback as this feature isn't yet supported in StaticPrefs.
Differential Revision: https://phabricator.services.mozilla.com/D31256
This commit adds categories to all markers. This way the profiler's
marker categories and frame label categories agree. There are a few
duplicate category properties on some of the marker payloads, but
this could be cleaned up in a follow-up if needed.
Differential Revision: https://phabricator.services.mozilla.com/D16864
