----- "Robert O'Callahan" <[email protected]> wrote:
> Just extract the subimage at the last moment, as you are currently doing.
>
> We shouldn't really have to extract an image at all. We only do it to
> get the right repeat/pad behaviour. At some point that will be fixed in
> the graphics layer; we'll still extract an image, but it will be a
> "virtual" image and in some/most cases we won't need to actually copy the
> data.
I'm sorry for asking many questions, but I am now thinking where is the best
place to call nsIImage::Extract(). I could just call Extract() in
nsCSSRendering.cpp as -moz-border-image property does, but here is my concern.
If we seriously consider adopting Media Fragments Working Group proposal of
spatial fragments (cropped images) in the future, any CSS properties and HTML
elements which take an image url must to be able to handle spatial fragments.
Also, I think we want to be able to use -moz-image-rect() in place of url() for
any CSS properties which take url(). So, I think it's nice to have a higher
level of abstraction for images that hide the details of cropping so that we
can treat cropped images just like usual images. For instance,
class nsVirtualImage {
nsCOMPtr<imgIRequest> mImage;
nsImageRect mRect;
PRInt32 GetWidth();
PRInt32 GetHeight();
// Checks if the cropped region has any pixels to be painted
PRBool IsOpaque();
// Extract sub image lazily (doesn't call nsIImage::Extract)
nsresult Extract(const nsImageRect& aRect, nsVirtualImage** aExtractedImage);
...
};
// This util function strips off a URI fragment
"#xywh=<x>,<y>,<width>,<height>" of aURI
nsContentUtils::LoadImage(nsIURI* aURI, nsImageRect& aRect, ...,
nsVirtualImage** aResult);
// This internally calls nsIImage::Extract()
nsLayoutUtils::DrawImage(nsVirtualImage* aImage, ...);
This way, we can also simplify complex use cases like:
-moz-border-image: url(foo.png#xywh=0,0,100,100) 27 27 27 27
Let me know if this is just an overkill and/or more confusing.
_______________________________________________
dev-tech-layout mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-tech-layout
