1628532 - OrientedImage use of WillDrawOpaqueNow isn't great

Status: RESOLVED FIXED

(Core :: Graphics: ImageLib, defect)

Description

[Timothy Nikkel (:tnikkel)]

WillDrawOpaqueNow tries to answer the question "if Draw is called on this image 'pretty soon' from now will it draw something opaque (so I know if I can cull stuff behind it for painting)".

But OrientedImage wants "is the frame I have right now opaque (so I can choose the right format for a surface I'm trying the flipped image into)".

WillDrawOpaqueNow checks the lock count, which is irrelevant for OrientedImage use case (we already have the surface) and it calls LookupBestMatch, which means it could be returning a difference surface than the one OrientedImage got, so whether or not the surface is finished decoding could differ between these two surfaces.

Comment 1

[Timothy Nikkel (:tnikkel)]

Attachment: Bug 1628532. Don't use WillDrawOpaqueNow in OrientedImage::GetFrame. r?aosmond

WillDrawOpaqueNow tries to answer the question "if Draw is called on this image 'pretty soon' from now will it draw something opaque (so I know if I can cull stuff behind it for painting)".

But OrientedImage wants "is the frame I have right now opaque (so I can choose the right format for a surface I'm trying to draw the flipped image into)".

Bug 1260324 replaces imgIContainer::IsOpaque with WillDrawOpaquaNow, but it should have considered this case a bit more.

RasterImage::GetFrame already checks if the surface is finished before returning, and we have the format on the returned frame, so we don't need anything complicated here.

Comment 2

[BugBot [:suhaib / :marco/ :calixte]]

Bugbug thinks this bug is a defect, but please change it back in case of error.

Comment 3

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/92d08b0cf559
Don't use WillDrawOpaqueNow in OrientedImage::GetFrame. r=aosmond

Comment 4

[Daniel Varga [:dvarga]]

https://hg.mozilla.org/mozilla-central/rev/92d08b0cf559