juan becerra [:juanb] Reporter
	Description • 11 years ago

Tested on 2013-05-29 using latest nightly.

If you have a page like autoblog.com in snapped view and you snap it back to full view, you will see the page be stretched horizontally for a little while before it renders nicely.

Steps:
1. In Metro Firefox go to autoblog.com and put it in snapped view
2. Pull back the vertical divider to snapp it back to full view

Expected: Faster, smoother transition that doesn't show a stretched page.

Actual: You see the page stretch horizontally for a moment before it looks normal.

	Brian R. Bondy [:bbondy] Assignee
	Comment 1 • 11 years ago

p=2

	Jim Mathies [:jimm]
	Comment 2 • 11 years ago

'OMTC window resizing doesn't really work' bug 899435 may be related to this.

	Jim Mathies [:jimm]
	Comment 3 • 11 years ago

(In reply to Jim Mathies [:jimm] from comment #2)
> 'OMTC window resizing doesn't really work' bug 899435 may be related to this.

This has landed, can anyone still reproduce?

	Allison Naaktgeboren :ally
	Comment 4 • 11 years ago

I tested this on todays m-c and it works for me. I'm concerned the problem Juan reported might a function of slow hardware, which I am not on. Juan, on the original hardware, can you reproduce this?

	Brian R. Bondy [:bbondy] Assignee
	Comment 5 • 11 years ago

I can reproduce this consistently, it's easiest to see when you start with snapped view and you go to a larger size.

	Brian R. Bondy [:bbondy] Assignee
	Comment 6 • 11 years ago

We were originally hoping that bug 899435 would fix this, but the case covered in that bug was not hit here.

On the Swap Chain's ResizeBuffer call, the swap desc was set to scale, this caused a stretching effect to be displayed.
There is also some visual jank that happens because of resizing that is fixed by the flag passed to present.  I think this is because we have 2 buffers in our swap chain for WinRT but not anywhere else.

	Benoit Jacob [:bjacob] (mostly away)
	Comment 7 • 11 years ago

Comment on attachment 804483 [details] [diff] [review]
Patch 1 - Do not scale on resize and use current buffer after resize

I am not competent to review this. Try Bas (I think he'll be back from vacation on Monday) or Jeff Gilbert.

	Kelsey Gilbert [:jgilbert]
	Comment 8 • 11 years ago

Comment on attachment 804483 [details] [diff] [review]
Patch 1 - Do not scale on resize and use current buffer after resize

Bas should handle this. I could figure it out, but Bas will have intuition for this part of the code.

	Brian R. Bondy [:bbondy] Assignee
	Comment 9 • 11 years ago

Thanks for the quick review!

	Brian R. Bondy [:bbondy] Assignee
	Comment 10 • 11 years ago

https://hg.mozilla.org/integration/mozilla-inbound/rev/41104c4a62ee

	Ryan VanderMeulen [:RyanVM]
	Comment 11 • 11 years ago

https://hg.mozilla.org/mozilla-central/rev/41104c4a62ee

	Brian R. Bondy [:bbondy] Assignee
	Comment 12 • 11 years ago

Removing bug 831086 because it's not related to this bug.

	Manuela Muntean [Away]
	Comment 13 • 11 years ago

While testing this for iteration #15, with latest Nightly (build ID: 20130926145500), I can't see the page stretch horizontally, before it looks normal.

On the other hand, I do see some visual jank in the upper left corner on the page that lasts for 3-4 seconds, after I put Metro back in full view.

Does anyone have any thoughts/suggestions? Thanks!

	Brian R. Bondy [:bbondy] Assignee
	Comment 14 • 11 years ago

You may be seeing bug 918203.  This bug just gets rid of the stretching effect.

	Manuela Muntean [Away]
	Comment 15 • 11 years ago

> You may be seeing bug 918203.  This bug just gets rid of the stretching
> effect.

Yes, is similar to bug 918203.

Marking this verified, based on comment 13 and comment 14. Thanks Brian!