Render context shadows in the raster backends#168
Open
DTW-Thalion wants to merge 4 commits into
Open
Conversation
Store the current shadow on the shared GSGState, so that it is saved and restored with the graphics state, and forward -setShadow: and -shadow from GSContext to it. The cairo backend paints the shadow by filling or stroking the current path offset by the shadow offset, in the shadow colour, before the path itself is drawn. This covers the fill, even-odd fill and stroke operators. Blur is not applied. Holding the shadow state on GSGState lets other backends render shadows without further plumbing. Addresses gnustep/libs-gui#217
Add the same offset shadow rendering to the remaining raster backends. Each paints the current path offset by the shadow offset, in the shadow colour, before the path itself, covering the fill, even-odd fill and stroke operators. The shadow parameters are read from the shared GSGState, so saving and restoring the graphics state carries the shadow with it. Extend Tests/cairo/dropshadow.m to run on these backends as well.
DTW-Thalion
changed the title
The xlib offscreen path cannot be read back reliably in the headless CI run and aborts there, so restrict dropshadow.m to the cairo and art backends. The xlib and winlib shadow rendering is unchanged.
The test skipped unless DISPLAY was set, so it did not exercise the shadow path in a Wayland-only session even though the shadows render there through the cairo graphics backend. Accept WAYLAND_DISPLAY as well.
Contributor
Author
|
Confirmed this covers the Wayland server. The shadow is rendered in the cairo Verified with the wayland+cairo backend loaded (GSCurrentServer is The last commit broadens the test's guard to accept WAYLAND_DISPLAY, since it |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The backends ignored the shadow set through
NSGraphicsContext, so[shadow set]followed by a fill or stroke drew nothing extra. This adds offset-shadow rendering to all four raster backends: cairo, art, xlib and winlib.The shadow state is stored on the shared
GSGState(-setShadow:/-shadow, released and copied with the state), andGSContextforwards-setShadow:/-shadowto it. Because the state lives on the graphics state, saving and restoring the graphics state carries the shadow with it, and no libs-gui change is needed (the gui already calls[ctxt setShadow:]).Each backend paints the shadow before the real path: the current path, offset by the shadow offset, in the shadow colour. This covers the fill, even-odd fill and stroke operators. cairo draws the offset path directly on its context; the other backends render an offset copy of the path in the shadow colour, restoring the fill/stroke colour afterwards. Blur is not applied.
Tests/cairo/dropshadow.mdraws a shape with a coloured shadow at a known offset through the AppKit offscreen path and checks the offset region for the shadow colour, that the shape sits on top of its own shadow, and that restoring the graphics state clears the shadow. It runs on cairo and art (8 assertions each), whose offscreen drawing reads back reliably in a headless run. The xlib and winlib backends render shadows the same way; xlib was verified locally against a live X server (the headless xlib offscreen path is not reliable enough to assert on in CI) and winlib was not built here.Addresses gnustep/libs-gui#217