Closed
Bug 695406
Opened 13 years ago
Closed 13 years ago
Need reset front buffer if ContentType is different
Categories
(Core :: Graphics, defect)
Tracking
()
RESOLVED
FIXED
mozilla10
People
(Reporter: romaxa, Assigned: romaxa)
References
Details
(Keywords: regression)
Attachments
(2 files)
3.93 KB,
patch
|
Details | Diff | Splinter Review | |
7.73 KB,
patch
|
cjones
:
review+
|
Details | Diff | Splinter Review |
Looks like we are not dropping front buffer if content type is different. OGL/Basic, Shadow layers are affected
Assignee | ||
Comment 1•13 years ago
|
||
Assignee | ||
Updated•13 years ago
|
Keywords: regression
Assignee | ||
Updated•13 years ago
|
Attachment #567810 -
Flags: review?(jones.chris.g)
Comment 2•13 years ago
|
||
I think we need to also include part of the changes from https://bugzilla.mozilla.org/attachment.cgi?id=567936&action=diff here. This patch deletes the front buffer if the new front buffer has a different content type. We also need to detect the actual content type change on the child side, and create a new backbuffer before this code will ever be hit. With this change, the BasicLayers changes are unnecessary since we will delete this buffer on the next frame paint. Though probably still a good idea.
Comment 3•13 years ago
|
||
Added in the check on the backbuffer side.
Attachment #567955 -
Flags: review?(jones.chris.g)
Is this leading to bugs in the field (seems like it could!), and/or is it breaking bug 695275? If the former, we need tests here.
Comment on attachment 567955 [details] [diff] [review] Reset all buffers if ContentType has changed I assume this obsoletes the previous patch?
Attachment #567955 -
Flags: review?(jones.chris.g) → review+
Assignee | ||
Comment 6•13 years ago
|
||
Comment on attachment 567810 [details] [diff] [review] Reset front buffer if content type has changed yes, it is obsolete
Attachment #567810 -
Flags: review?(matt.woodrow)
Attachment #567810 -
Flags: review?(jones.chris.g)
Assignee | ||
Updated•13 years ago
|
Keywords: checkin-needed
Comment 7•13 years ago
|
||
Just the latter. I'm not sure how to test this exactly, nsDisplayImages are always marked as being transparent, we only hit this bug in the weird case that theres an empty visible region (and thus empty transparent region), but still decide to create the image layer. Constructing a test that relies on this edge case doesn't sound great.
Comment 8•13 years ago
|
||
https://hg.mozilla.org/integration/mozilla-inbound/rev/73dc291f8974
Whiteboard: [inbound]
Comment 9•13 years ago
|
||
https://hg.mozilla.org/mozilla-central/rev/73dc291f8974
Status: ASSIGNED → RESOLVED
Closed: 13 years ago
Keywords: checkin-needed
Resolution: --- → FIXED
Whiteboard: [inbound]
Target Milestone: --- → mozilla10
Comment 10•13 years ago
|
||
I backed out and relanded this to investigate an orange, thus the real final changeset is https://hg.mozilla.org/mozilla-central/rev/75eaad17724f
You need to log in
before you can comment on or make changes to this bug.
Description
•