Opened 2 years ago
Last modified 17 months ago
#17665 in-progress bug
WebKit: Text disappears and bad content clipping with opacity<1 and transform:rotate
| Reported by: | thebuck | Owned by: | madmax |
|---|---|---|---|
| Priority: | high | Milestone: | Unscheduled |
| Component: | Servers/app_server | Version: | R1/Development |
| Keywords: | Cc: | nephele | |
| Blocked By: | Blocking: | ||
| Platform: | All |
Description (last modified by )
This bug has been split out from #12511 at nephele's request.
When a HTML element is styled with e.g. opacity: 0.99; transform: rotate(110deg), text within is completely invisible. The element is additionally clipped at a vertical line on the right which goes through the element's transformed top right corner (i.e. nothing to the right of that corner (plus a little offset) is visible).
Clipping suspected here:
GraphicsContextHaiku::clipBounds()
Example of a better implementation: TransformationMatrix::mapRect
Attachments (7)
Change History (14)
by , 2 years ago
| Attachment: | opacity-transform.html added |
|---|
comment:1 by , 2 years ago
| Description: | modified (diff) |
|---|
comment:2 by , 2 years ago
| Cc: | added |
|---|
by , 2 years ago
| Attachment: | 0001-GraphicsContextHaiku-add-tracing.patch added |
|---|
Patch to enable tracing in webkit GraphicsContextHaiku
comment:3 by , 2 years ago
I've added Tracing to haikuwebkit to try and narrow this down, haven't looked much at the trace yet, but there seems to be a bit more going on than just transparency. Atleast it is visible that webkit does ask it to do transparency. Maybe the drawing in app_server is at fault for this case.
comment:4 by , 2 years ago
(accidentally added an old trace, where it sais "beginTransparencyLayer: no values" It should say "endTransparencyLayer: no values")
comment:5 by , 2 years ago
| Owner: | changed from to |
|---|---|
| Status: | new → in-progress |
comment:6 by , 18 months ago
More to the point, IntRect GraphicsContextHaiku::clipBounds() const cannot be correct for transformations other than translate/scale because it ensures visibility of only two of the four rectangle corners.
Taking a 45°-rotated square as example, it will be entirely(*) clipped away.
(*) IntRect shall keep a one pixel row or column due to its extend-only rounding scheme (not sure whether that is properly implemented, though).
Determining the (wrong) bounding rectangle of a transformed bounding rectangle produces an unnecessarily big rectangle anyway. Could the region.Frame() be called such that it takes the view transformation into account by itself?
comment:7 by , 17 months ago
| Component: | Kits/Web Kit → Servers/app_server |
|---|
Except for trying to get the smallest bounding rectangle for a multipart region, that's fixed in master haikuwebkit. The problem with this ticket (transformed opacity layers) lies, at least in great part, in app_server, spread between alphamasks, pictures and drawing state handling.
Testcase: Hover the mouse over the skyblue element to rotate it. Un-/comment lines which have a comment in the style code to alter behaviour. I used hashes (#) to make CSS declarations invalid instead of commenting them properly out.