On 15/7/09 8:32 AM, Ryo Kawaguchi wrote:
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.
It's not needed. See https://bugzilla.mozilla.org/show_bug.cgi?id=753, which will let us use imgIContainer for this purpose.
Rob _______________________________________________ dev-tech-layout mailing list [email protected] https://lists.mozilla.org/listinfo/dev-tech-layout
