rectangle shadow #5841

Vinci10 · 2025-07-04T15:03:41Z

Description:

(Based on #5830)
Fixes:

#4129 (shadows only)
#4411 (shadows on the right and bottom can be added using proper offset)

Shadow Support for Rectangle, Square, and Circle

Introduced a Shadow struct and Shadowable interface to provide reusable shadow logic.
Added fields for shadow color, softness, offset, and type (drop/box shadow).
~~The ExpandForShadow field allows the object to keep its requested/original size, expanding the total bounds to include the shadow.~~
Updated shader and painter logic to render shadows with configurable softness and offset, and to blend shadows correctly.
If a canvas object has a shadow added, the canvas size is reduced by the shadow paddings on each side. This ensures that the entire object—including its shadow—fits within the originally requested frame size. The content area (without shadow) will be smaller to accommodate the shadow within the allocated space. If a canvas object has a shadow added, the canvas coords are expanded to accommodate the shadow.
Shader and Painter Updates
- Rectangle and round-rectangle shaders updated to support shadow rendering.
- Painter logic updated to pass new parameters and handle shadow bounds.
API Additions
- New methods and fields are documented in code comments.
- Backwards compatibility is maintained for existing code.

Status

This is a draft PR.
I am looking for feedback and suggestions from the Fyne team regarding:
- API design and naming
- Performance considerations
Tests are not yet included.
Performance has not been fully evaluated.

Additional Notes

This work is a prerequisite for adding shadows and rounded corners to popups, dialogs, and menus in Fyne. I have already applied these changes to those components and have working code locally. Rectangle shadow provides the necessary foundation for theme-level enhancements.

Examples

Dialog, menu shadow (preview)

Please let me know if you have any suggestions, concerns, or requests for changes.

Checklist:

Tests included.
Lint and formatter run with no errors.
Tests all pass.

Where applicable:

Public APIs match existing style and have Since: line.
Any breaking changes have a deprecation path or have been discussed.
Check for binary size increases when importing new modules.

Vinci10 · 2025-07-04T15:04:41Z

By default, adding a shadow currently impacts the geometry: the canvas size is reduced by the shadow paddings so that both the object and its shadow fit inside the requested frame. This means the content (e.g., a rectangle) is shrunk to ensure the shadow does not overflow the frame.

To address this, I introduced the ExpandForShadow option. When set to true, the object keeps its requested/original size, and the overall canvas size is increased to fit the shadow outside the content.

Example Calculations

Example 1

Suppose you have a rectangle with a requested frame size of 150 x 250.

Shadow parameters:
- Offset: (-10, 15)
- Softness: 8

Shadow paddings calculation:

Left: offsetX + softness = -10 + 8 = -2 (clamped to 0)
Top: -offsetY + softness = -15 + 8 = -7 (clamped to 0)
Right: -offsetX + softness = 10 + 8 = 18
Bottom: offsetY + softness = 15 + 8 = 23

After clamping negatives to zero:

Left: 0
Top: 0
Right: 18
Bottom: 23

Mode	Rectangle Size	Canvas Size	Rectangle Position	Canvas Position
No shadow	150 x 250	150 x 250	(0, 0)	(0, 0)
Shadow, ExpandForShadow=false	132 x 227	150 x 250	(0, 0)	(0, 0)
Shadow, ExpandForShadow=true	150 x 250	168 x 273	(0, 0)	(0, 0)

Example 2

Suppose you have a rectangle with a requested frame size of 100 x 100.

Shadow parameters:
- Offset: (12, -6)
- Softness: 5

Shadow paddings calculation:

Left: 12 + 5 = 17
Top: 6 + 5 = 11
Right: -12 + 5 = -7 (clamped to 0)
Bottom: -6 + 5 = -1 (clamped to 0)

After clamping negatives to zero:

Left: 17
Top: 11
Right: 0
Bottom: 0

Mode	Rectangle Size	Canvas Size	Rectangle Position	Canvas Position
No shadow	100 x 100	100 x 100	(0, 0)	(0, 0)
Shadow, ExpandForShadow=false	83 x 89	100 x 100	(17, 11)	(0, 0)
Shadow, ExpandForShadow=true	100 x 100	117 x 111	(0, 0)	(-17, -11)

Notes:

When ExpandForShadow is false, the rectangle is shrunk and shifted inside the canvas to fit the shadow, so the rectangle's position changes (by the left/top padding), but the canvas position remains the same.
When ExpandForShadow is true, the rectangle keeps its original position and size, but the canvas itself is shifted (by the left/top padding) to ensure the rectangle appears at the requested position, and the overall canvas size is increased to fit

This approach allows developers to choose whether the shadow should be included inside the original frame (shrinking the content) or expand the overall bounds to preserve the content size.

Please let me know if you’d like further clarification or adjustments to this behavior!

andydotxyz · 2025-07-04T15:41:11Z

Copying from the wider discussion as it pertains to the API design here.

You realise that an object is not restricted to drawing in its "frame"?

I don't think we should add more APIs to control how the geometry will be interpreted, it will just lead to confusion.
Simple and standard is the way - provide the "path of least surprise".

I don't think the presence of a shadow should change how the geometry of a widget or shape is interpreted at all. With the maths illustrations above complexity goes up substantially and widgets with shadows will no longer line up with others which breaks the simplicity of our layout model.

andydotxyz · 2025-07-04T15:43:07Z

#4411 (shadows on the right and bottom can be added using proper offset)

Just FYI on that one, the bug is not about the drop of the shadow or its depth - the report is that a menu popping up from a menu bar should be at the same level so there should be shadow on 3 sides of the menu and the underside of the bar, but not between them (top of the menu)

andydotxyz · 2025-07-04T15:47:03Z

canvas/base_shadow.go

+	// with the input size. Total size is larger than the input size.
+	SizeAndPositionWithShadow(size fyne.Size) (fyne.Size, fyne.Position)
+	// ShadowPaddings returns the paddings (left, top, right, bottom) for the shadow.
+	ShadowPaddings() [4]float32


This seems like the only one of the interface methods that adds (rather than works around geometry complications).

However I wonder if ShadowOffset and ShadowDepth really are all we need to draw shadows around objects - all these calculations could be removed and made a rendering only complexity.

So all calculations should be moved to painter draw.go file ?

The interface has been updated. Now only the ShadowPaddings method is available

Thanks. As noted on the recent review now that it is reduced to padding calculations it seems not needed at all...

andydotxyz · 2025-07-04T15:48:52Z

canvas/base_shadow.go

+type baseShadow struct {
+	baseObject
+
+	ShadowColor    color.Color   // Color of the shadow.


One API consideration for this PR should be:

Is the shadow a themed colour or a canvas feature

Which impacts how it should be implemented. If widgets are to have shadows it must be in the theme - but for canvas objects you get lower level control. Worth considering in the bigger picture how this replaces the existing (gradient) shadow implementation.

We should replace old with new in the scope of this PR rather than having two different shadow implementations - plus it will inform the correct API.

What about gradient shadow implementation if only one-side shadow is needed like for scroll ? I think it still may be useful, but I could be wrong

Yes a fair point - but for the major shadow usages (where it is a complete shadow) we should replace and test

I replaced ShadowingRenderer and updated tests. I started with some initial values for shadow parameters which should be adjusted to make shadow looking good. I still need to update macos and mobile tests. I can start fixing tests once final shadow parameters per object (dialogs, widgets, etc.) are determined.

andydotxyz · 2025-07-04T15:50:31Z

Very cool indeed thanks. I have made a few API /design comments inline.

Another thing to note would be that we have also the software renderer which would need to understand this new feature and draw something similar for compatibility.
This would also open up easier unit testing.

Vinci10 · 2025-07-04T16:05:42Z

#4411 (shadows on the right and bottom can be added using proper offset)

Just FYI on that one, the bug is not about the drop of the shadow or its depth - the report is that a menu popping up from a menu bar should be at the same level so there should be shadow on 3 sides of the menu and the underside of the bar, but not between them (top of the menu)

You're right, the top shadow is the problem there. I just wanted to point out that a rectangular shadow may help with that.

Copying from the wider discussion as it pertains to the API design here.

You realise that an object is not restricted to drawing in its "frame"?

I don't think we should add more APIs to control how the geometry will be interpreted, it will just lead to confusion.
Simple and standard is the way - provide the "path of least surprise".

I don't think the presence of a shadow should change how the geometry of a widget or shape is interpreted at all. With the maths illustrations above complexity goes up substantially and widgets with shadows will no longer line up with others which breaks the simplicity of our layout model.

I also prefer simple solutions :) To be honest, I am not an expert in such graphical implementations. The biggest challenge was to draw the shadow correctly and that's what I focused all my attention on. However, all changes in geometry were made only to "see" the desired effect, because without any change the "frame" clipped the shadow and I was not able to assess whether it was drawing correctly. That's why I am open to any suggestions regarding the API and changes on the library side.

andydotxyz · 2025-07-04T16:24:41Z

because without any change the "frame" clipped the shadow

This will be a limitation of the rendering and not part of the Fyne geometry design. If you look at rectangle, line and others you will see a vectorPad value which is how we expand the frame to draw outside of the original rectangle if required. Expanding that to accommodate your new shadow should fix the issue and all the geometry changes can be reverted.

Vinci10 · 2025-07-04T16:40:19Z

because without any change the "frame" clipped the shadow

This will be a limitation of the rendering and not part of the Fyne geometry design. If you look at rectangle, line and others you will see a vectorPad value which is how we expand the frame to draw outside of the original rectangle if required. Expanding that to accommodate your new shadow should fix the issue and all the geometry changes can be reverted.

That would be great, so I can just extend vectorPad by shadow paddings and it would work? I will test that approach

I don't fully understand how Fyne's design geometry works, and that's why I added so much unnecessary code.

andydotxyz · 2025-07-04T17:01:37Z

That would be great, so I can just extend vectorPad by shadow paddings and it would work? I will test that approach

Yes

I don't fully understand how Fyne's design geometry works, and that's why I added so much unnecessary code.

In essence it is really simple - a device agnostic coordinate system so it's consistent across all devices. Every item is positioned relative to the parent. More info at https://docs.fyne.io/architecture/geometry

Vinci10 · 2025-07-16T12:28:44Z

I reverted geometry changes. As of now shadow paddings expand coords in vecRectCoordsWithPad method. Please let me know if that is correct.

Result:

…onstraint

Vinci10 · 2025-07-23T10:48:42Z

I added shadow to software painter along with test cases

andydotxyz · 2025-07-25T17:24:09Z

I reverted geometry changes. As of now shadow paddings expand coords in vecRectCoordsWithPad method. Please let me know if that is correct.

Thanks, I appreciate that when packed together it looks peculiar but I think this is better for the geometry.
It does raise the question of whether shadows should be drawn below all other items, but I think that is maybe not needed and maybe for another time.

coveralls · 2025-07-25T17:29:10Z

coverage: 62.491% (+0.1%) from 62.391%
when pulling 8de9717 on Vinci10:rectangle_shadow
into 170ef1d on fyne-io:develop.

andydotxyz

Thanks for working more on this, it is coming together.

I have a few questions at this time:

Isn't the geometry in the software painter wrong? The objects are moving out of their position to accommodate the shadow
The Shadowable interface isn't clear - what is its purpose? It doesn't seem to be needed
The public Shadow type can only be used as embedded in other types - what are your thoughts on this balance?

andydotxyz · 2025-07-25T17:33:02Z

internal/painter/software/draw.go

+	if shadowColor != color.Transparent && shadowColor != nil && (!shadowOffset.IsZero() || shadowSoftness > 0.0) {
+		bounds = drawShadow(c, obj, fyne.NewSize(width, height), shadowSoftness, shadowOffset, shadowColor, 0, bounds, base, clip)
+		// due to shadow draw rectangle with a certain width and height
+		raw := painter.DrawRectangle(canvas.NewRectangle(fill), width, height, 0, func(in float32) float32 {


I don't understand this - is it the cause of test failures?
If the geometry is not changed then isn't it the same rectangle but drawn at a different offset?

to accomodate shadow the frame must be extended, without this change rectangle always fill in the entire space and the shadow is not visible

I see there is issue on macos platform, could you please show me the rendered images on macos so I can try to investigate the problem because on my local windows platform all tests succeed.

andydotxyz · 2025-07-25T17:41:28Z

canvas/shadow.go

+// Since: 2.7
+type Shadowable interface {
+	// ShadowPaddings returns the paddings (left, top, right, bottom) of the shadow.
+	ShadowPaddings() [4]float32


This seems to be derived from the public shadow struct data - what is the purpose of having a new interface with this method when it could be internal to the rendering?

The interface is useful when I have obj fyne.CanvasObject as an argument and want to quickly parse it to the new interface s, ok := obj.(canvas.Shadowable) to get paddings ShadowPaddings() but maybe there is a better approach without using new interface.

andydotxyz · 2025-07-25T17:44:33Z

canvas/rectangle.go

 // Rectangle describes a colored rectangle primitive in a Fyne canvas
 type Rectangle struct {
 	baseObject
+	// Support shadow configuration


Embedding at the beginning of the struct like this will break any code that has done &Rectangle{color.Transparent} - though that is not best practice we try to avoid breaking if we can.

thanks, I will move the embedding at the end of the struct

Vinci10 · 2025-07-28T16:11:45Z

Thanks for working more on this, it is coming together.

I have a few questions at this time:

Isn't the geometry in the software painter wrong? The objects are moving out of their position to accommodate the shadow

The Shadowable interface isn't clear - what is its purpose? It doesn't seem to be needed

The public Shadow type can only be used as embedded in other types - what are your thoughts on this balance?

Thanks for review.

Unfortunately, without changing object position when I expand the frame (to accommodate the shadow) the object is always located on the upper-left corner, in such case I cannot render and test shadow with upper-left offset properly. I am testing changes on WSL2 Ubuntu and the new tests succeed. Not sure what could be wrong :(
With interface it is easy to parse fyne.CanvasObject object to the new Shadowable interface and call ShadowPaddings() method. But probably it is not a good argument. I also thought the new interface would help with adding new shadow types in the future, but I'm not sure if it makes sense.
Sure, sounds good. So should it be a public struct and how should I call ShadowPaddings() method for fyne.CanvasObject objects ? Thanks in advance.

Which implementation is expected ?
a (embedded).

type Rectangle struct {
	baseObject

        // ....

	// Support shadow configuration
	//
	// Since: 2.7
	Shadow
}

b (public field).

type Rectangle struct {
	baseObject

        // ....

	// Support shadow configuration
	//
	// Since: 2.7
	Shadow shadow
}

Vinci10 · 2025-07-30T15:06:21Z

I have removed ShadowingRenderer and applied rectangle shadow to the following objects:

Containers:

InnerWindow

Widgets:

Card
Menu
Popup

Internal GLFW:

MenuBar

I would like to highlight that I set some initial values for the shadow softness and offset to show what it might look like and how the test might change. I was able to update some platform tests to be successful.
Could you please help me with finding proper values for shadow parameters for the objects so I can start fixing tests for mobile and other platforms.

Vinci10 · 2025-10-27T21:20:21Z

If you don't mind, I'd like to continue working on this feature for version 2.8.
I removed Shadowable interface, but the tests still need updating.

Vinci10 added 2 commits July 4, 2025 13:47

support rectangle shadow

09db729

fix circle radius

7be6f24

Vinci10 mentioned this pull request Jul 4, 2025

Rectangle shadow and partially rounded corners, edge smoothness improvements #5830

Closed

6 tasks

andydotxyz reviewed Jul 4, 2025

View reviewed changes

Vinci10 added 2 commits July 16, 2025 12:09

not impact object geometry by shadow

b708375

refactoring

46593b4

Vinci10 added 9 commits July 16, 2025 12:31

Merge remote-tracking branch 'origin/develop' into rectangle_shadow

ead9146

make shadow public

825e89c

add shadow for circle to software painter

bc00393

add shadow for rectangle without stroke and radius to software painter

baaec57

add shadow for rectangle with stroke and radius to software painter

4d5aa2a

add separate drawShadow function

ea154d4

update rectangle coords

e607936

add more test cases for shadow paddings, remove zero shadowSoftness c…

2e3f435

…onstraint

not draw shadow is offset and softness are 0

8de9717

andydotxyz requested changes Jul 25, 2025

View reviewed changes

Merge remote-tracking branch 'origin/develop' into rectangle_shadow

720ce1f

Vinci10 added 7 commits July 28, 2025 14:26

replace ShadowingRendered by rectangle shadow in popup widget

6d94375

replace ShadowingRendered by rectangle shadow in menu widget

c8344a6

replace ShadowingRendered by rectangle shadow in card widget

60819a8

replace ShadowingRendered by rectangle shadow in innerwindow container

1ae36c7

replace ShadowingRendered by rectangle shadow in menu bar

c96c844

remove ShadowingRenderer

e69e9cf

use initial shadow softness and offset values

bcee529

Vinci10 added 7 commits July 28, 2025 16:16

move new embedded Shadow field at the end of struct

00301d8

fix tests

95d7057

update tests

cf5e730

support DropShadow type in software painter

201220d

fix widget desktop tests

c47ff87

fix dialog desktop tests

c262332

fix tests

9dcb360

Vinci10 requested a review from andydotxyz July 30, 2025 15:44

Vinci10 added 4 commits October 27, 2025 14:09

Merge remote-tracking branch 'origin/develop' into rectangle_shadow

e158f0b

align shadow config

3d121ea

do not discard if outside rectangle coords when shadow is added

0ed3dda

remove shadowable interface, make ShadowPaddings function internal

d85de7b

small optimisation to shadow shader

e323cc2

Uh oh!

rectangle shadow #5841

Are you sure you want to change the base?

rectangle shadow #5841

Uh oh!

Conversation

Vinci10 commented Jul 4, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Description:

Status

Additional Notes

Examples

Dialog, menu shadow (preview)

Checklist:

Where applicable:

Uh oh!

Vinci10 commented Jul 4, 2025

Example Calculations

Example 1

Example 2

Uh oh!

andydotxyz commented Jul 4, 2025

Uh oh!

andydotxyz commented Jul 4, 2025

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

andydotxyz commented Jul 4, 2025

Uh oh!

Vinci10 commented Jul 4, 2025

Uh oh!

andydotxyz commented Jul 4, 2025

Uh oh!

Vinci10 commented Jul 4, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

andydotxyz commented Jul 4, 2025

Uh oh!

Vinci10 commented Jul 16, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Vinci10 commented Jul 23, 2025

Uh oh!

andydotxyz commented Jul 25, 2025

Uh oh!

coveralls commented Jul 25, 2025

Uh oh!

andydotxyz left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Vinci10 Jul 28, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Vinci10 commented Jul 4, 2025 •

edited

Loading

Vinci10 commented Jul 4, 2025 •

edited

Loading

Vinci10 commented Jul 16, 2025 •

edited

Loading

Vinci10 Jul 28, 2025 •

edited

Loading