Open
Bug 1028694
Opened 10 years ago
Updated 2 years ago
Using scale and rotate from javascript causes blurred resulting image
Categories
(Core :: Web Painting, defect)
Tracking
()
NEW
People
(Reporter: scu, Unassigned)
References
Details
(Keywords: regression, testcase)
Attachments
(2 files)
Moonscape.png
User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:30.0) Gecko/20100101 Firefox/30.0 (Beta/Release)
Build ID: 20140605174243
Steps to reproduce:
<!DOCTYPE html>
<html>
<head>
<style>
#Moonscape {
position: absolute;
left: 591px;
top: 350px;
opacity: 1;
width: 78px;
height: 59px;
transition: transform 2s;
}
</style>
<script>
function action() {
var moonscape = document.getElementById("Moonscape");
moonscape.style.transform = "scale(10) rotate(-60deg)";
}
</script>
</head>
<body onload="action()">
<img id="Moonscape" src="Moonscape.png">
</body>
</html>
Actual results:
Resulting image is blurred.
Expected results:
Image should be clear. This worked in last version of Firefox. Now using version 30.0.
|
||
Comment 1•10 years ago
|
||
|
|
||
Comment 2•10 years ago
|
||
I see this on Linux as well; seems like we're making a pretty awful decision about what resolution the layer should be sampled at or something like that.
Status: UNCONFIRMED → NEW
Component: CSS Parsing and Computation → Layout: View Rendering
Ever confirmed: true
OS: Windows 7 → All
Hardware: x86_64 → All
|
|
||
Comment 3•10 years ago
|
||
One-day regression window from Linux nightlies is:
https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=4cb766685b73&tochange=529b86b92b1d
(Note that I have layers.acceleration.force-enabled on; that might make a difference, but I haven't checked.)
|
|
||
Comment 4•10 years ago
|
||
The one-day mozilla-inbound regression range is:
https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=a35f5f30cd53&tochange=6beb83e91a7d
(that's 2014-02-28 to 2014-03-01 nightlies, unlike mozila-central which is 2014-03-03 to 2014-03-04)
|
|
||
Comment 5•10 years ago
|
||
I think the range in common is thus:
https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=1f082a704d6d&tochange=6beb83e91a7d
|
|
||
Comment 6•10 years ago
|
||
Aha, probably a regression from bug 854795.
(My second choice would be something in https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?changeset=4895aa1f1ee5 , but that seems much less likely now that I spotted bug 854795.)
Blocks: 854795
Flags: needinfo?(jmuizelaar)
|
|
||
Comment 7•10 years ago
|
||
Although actually bug 854795 looks like it's pretty-well disabled (and would also only affect JPEG images).
No longer blocks: 854795
|
|
||
Updated•10 years ago
|
Flags: needinfo?(jmuizelaar) → needinfo?(matt.woodrow)
|
||
Comment 8•10 years ago
|
||
Unfortunately I can't reproduce this at all on OSX. I'll take a look when I next boot into linux.
Assignee: nobody → matt.woodrow
Flags: needinfo?(matt.woodrow)
|
||
Comment 9•10 years ago
|
||
I narrowed this down to https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=ae723aa8b528&tochange=68cb672eba84 (on Windows 7)
=> Bug 971720/Bug 976877
Keywords: regression,
testcase
|
|
||
Comment 10•10 years ago
|
||
Reproduced it on windows 7.
This is caused by us using downscaled copies of the image, and not taking CSS transforms (or the current context transform) into account.
We were previously using an inactive ImageLayer for drawing this, and that code path never uses the cached scaled version of the image. It's possible to construct a version of this testcase that was always broken (include something other than the image within the transform).
So I think there's two bugs here:
1) We attempt to use an image scaled to the requested image size, regardless of any transforms that might be applied.
2) RasterImage::GetCurrentImage() doesn't ever use the scaled version, so we might be uploading a massive image to the GPU when we don't need to.
Any ideas on the above seth?
Assignee: matt.woodrow → nobody
Flags: needinfo?(seth)
|
||
Updated•10 years ago
|
Depends on: DrawAPIRefactor
Flags: needinfo?(seth)
|
|
||
Comment 11•10 years ago
|
||
Can someone on Windows verify that this was fixed by bug 1037713, which has landed and should be in Nightly now?
Keywords: verifyme
|
|
||
Comment 12•10 years ago
|
||
Actually, nevermind. I see this happening on a retina display on OS X. Removing verifyme and needinfo'ing myself to investigate further. The odds are good that this is the same bug as bug 1038309, but I need to verify that.
Flags: needinfo?(seth)
Keywords: verifyme
|
||
Comment 13•8 years ago
|
||
The reporter's testcase is WFM using Nightly 49.0a1 (2016-05-21)on Windows 10 desktop.
|
Assignee | |
Updated•6 years ago
|
Component: Layout: View Rendering → Layout: Web Painting
|
||
Comment 14•2 years ago
|
||
Clear a needinfo that is pending on an inactive user.
For more information, please visit auto_nag documentation.
Flags: needinfo?(seth.bugzilla)
|
||
Updated•2 years ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•