Translucency support broken in cairogfx builds

RESOLVED FIXED

Status

()

Core
Graphics
RESOLVED FIXED
11 years ago
11 years ago

People

(Reporter: neil@parkwaycc.co.uk, Assigned: vlad)

Tracking

({regression})

Trunk
x86
Windows XP
regression
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(2 attachments)

(Reporter)

Description

11 years ago
Created attachment 258842 [details]
Test case (use with -chrome)

Although the attachment's <window> has no background, thus triggering translucency, its contents are completely opaque and should obscure everything. This works correctly in a 1.9a2 windows gfx build, but with cairogfx the alpha appears to be completely transparent (which can lead to some surprising effects as the RGB values are expected to be premultiplied but are not) unless you only draw a translucent PNG image in which case the alpha is calculated correctly.
Created attachment 259603 [details] [diff] [review]
fix

This should fix it; the problem is that we create a 32bpp DIB manually, and then hand the DC to gfxWindowsSurface; the cairo win32 surface needs to create all 32-bit DIBs itself so that it can keep track of various bits needed to make the alpha work.  So, we just create a gfxWindowsSurface and grab its DC.

nsWindow.cpp for win32 really needs to be cleaned up a bit, but that should be done separately from this.
Assignee: nobody → vladimir
Status: NEW → ASSIGNED
Attachment #259603 - Flags: review?(pavlov)
(Reporter)

Updated

11 years ago
Blocks: 375403

Comment 2

11 years ago
Comment on attachment 259603 [details] [diff] [review]
fix

please file a followup bug on cleaning up that code/removing the cairo ifdefs?
Attachment #259603 - Flags: review?(pavlov) → review+
Checked in; there's a bug already on file on the win32 nsWindow cleanup, need to dig it up.
Status: ASSIGNED → RESOLVED
Last Resolved: 11 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.