All its members are optional, so we can just use it as a plain struct
rather than Maybe<> all around, which simplifies the code and prevents
silly bugs like bug 1779592.
Mostly automatic via:
rg -l 'SVGImageContext' . | xargs sed -i 's/Maybe<SVGImageContext>/SVGImageContext/g'
With trivial build fixes.
Not intended to change behavior.
Differential Revision: https://phabricator.services.mozilla.com/D151846
We'll probably want to do something more accurate in the future with a
custom clang static analysis pass which validates that XPIDL interfaces
have the expected vtable and struct layout, however doing so would be
more involved than the string matching done in this patch.
In addition to checking for extra virtual methods, we'll likely also
want to check for data members on interfaces, and reject them unless the
class is marked as `[builtinclass]` in addition to some other attribute
which we'll need to add to prevent them from being implemented in Rust
(as c++ data members will not be reflected by the rust macro).
There were 2 instances of a comment which contained the word 'virtual'
within a CDATA block. These comments were moved out of the CDATA block
to avoid triggering the error.
Differential Revision: https://phabricator.services.mozilla.com/D151068
This will be used by layers as a replacement for ImageContainer's
ContainerProducerID for tracking if the same imgIRequest/imgIContainer
own the cached WebRenderImageProvider.
Differential Revision: https://phabricator.services.mozilla.com/D126598
In later parts in this series, GetImageProvider will replace
GetImageContainerAtSize. This will be a more specialized and lower
overhead means to get a wr::ImageKey for a particular surface.
Differential Revision: https://phabricator.services.mozilla.com/D126596
This will be used by layers as a replacement for ImageContainer's
ContainerProducerID for tracking if the same imgIRequest/imgIContainer
own the cached WebRenderImageProvider.
Differential Revision: https://phabricator.services.mozilla.com/D126598
In later parts in this series, GetImageProvider will replace
GetImageContainerAtSize. This will be a more specialized and lower
overhead means to get a wr::ImageKey for a particular surface.
Differential Revision: https://phabricator.services.mozilla.com/D126596
This will be used by layers as a replacement for ImageContainer's
ContainerProducerID for tracking if the same imgIRequest/imgIContainer
own the cached WebRenderImageProvider.
Differential Revision: https://phabricator.services.mozilla.com/D126598
In later parts in this series, GetImageProvider will replace
GetImageContainerAtSize. This will be a more specialized and lower
overhead means to get a wr::ImageKey for a particular surface.
Differential Revision: https://phabricator.services.mozilla.com/D126596
This patch has no functional change beyond changing prototypes and
adding storage for ImageIntRegion for each ImageContainer.
Differential Revision: https://phabricator.services.mozilla.com/D114984
Since we don't support downscaling animated images we'll need something like this even we were to try to request a smaller sized decode.
Differential Revision: https://phabricator.services.mozilla.com/D71523
This makes EXIF orientation metadata honored by default.
Introduce OrientedPixel and UnorientedPixel typed rects and sizes and
use them throughout RasterImage so that we don't confuse which we want.
The reason for doing this rather than having the imgLoader wrap every
RasterImage it creates with an OrientedImage is that returning the
wrapper messes with various notifications, as OrientedImage is not an
ImageResource.
(It would be even better if the JPEG decoder could decode to imgFrames
handling the EXIF orientation itself, but that's a more complicated
change.)
Differential Revision: https://phabricator.services.mozilla.com/D70273
This makes EXIF orientation metadata honored by default.
Introduce OrientedPixel and UnorientedPixel typed rects and sizes and
use them throughout RasterImage so that we don't confuse which we want.
The reason for doing this rather than having the imgLoader wrap every
RasterImage it creates with an OrientedImage is that returning the
wrapper messes with various notifications, as OrientedImage is not an
ImageResource.
(It would be even better if the JPEG decoder could decode to imgFrames
handling the EXIF orientation itself, but that's a more complicated
change.)
Differential Revision: https://phabricator.services.mozilla.com/D70273
--HG--
extra : moz-landing-system : lando
With WebRender, we had observed that the print preview for animated
images was not displaying correctly. It should display the first frame
but it was showing nothing the first time the preview was opened. Once
the decoded image was available in the cache, it would display
correctly if the preview was reloaded.
The StartDecoding and RequestDecode variants always requested
FRAME_CURRENT for animated images. They should use FRAME_FIRST for
static requests / FrozenImage. Correcting this fixes the print preview.
Differential Revision: https://phabricator.services.mozilla.com/D32033
The img decode API allows a web author to request that an image be
decoded at its intrinsic size and be notified when it has been
completed. This is useful to ensure an image is ready to display before
adding it to the DOM tree -- this will help reduce flickering.
Differential Revision: https://phabricator.services.mozilla.com/D11362
When the underlying image request (imgIRequest) changes for an image, we
need to ensure that we invalidate the cached WebRenderImageData such that
the image container stored therein is updated to be for the correct
image. This gets a little tricky because some display items store both
the current and previous images, and choose to display the latter if the
former is not yet ready. We also don't know what image the image
container belongs to. As such, we now compare the producer ID of the
current frame in the image container, to the expected producer ID of the
current image request. If they don't match, we must regenerate the
display list.
Differential Revision: https://phabricator.services.mozilla.com/D19699
Summary: Really sorry for the size of the patch. It's mostly automatic
s/nsIDocument/Document/ but I had to fix up in a bunch of places manually to
add the right namespacing and such.
Overall it's not a very interesting patch I think.
nsDocument.cpp turns into Document.cpp, nsIDocument.h into Document.h and
nsIDocumentInlines.h into DocumentInlines.h.
I also changed a bunch of nsCOMPtr usage to RefPtr, but not all of it.
While fixing up some of the bits I also removed some unneeded OwnerDoc() null
checks and such, but I didn't do anything riskier than that.
In addition to the image container, the draw result can also be useful
for callers to know whether or not the surface(s) in the container are
fully decoded or not. This is used in subsequent parts to avoid
flickering in some cases.
