Cellophane doesn't work with gradients

[takikawa]

The cellophane function doesn't appear to work as expected when gradients are used, e.g., in a dc pict.

Example:

#lang racket

(require pict
         racket/draw)

(define (rectangle/2t width height 
                      #:border-width [border-width 1]
                      #:border-color [border-color "black"]
                      #:color-1 [color-1 "white"]
                      #:color-2 [color-2 "black"])
  (dc (λ (dc dx dy)
        (define old-brush (send dc get-brush))
        (define old-pen (send dc get-pen))
        (define gradient
          (make-object linear-gradient%
                       dx dy
                       dx (+ dy height)
                       (list (list 0 (make-object color% color-1))
                             (list 1 (make-object color% color-2)))))
        (send dc set-brush (new brush% [gradient gradient]))
        (send dc set-pen (new pen% [width border-width]
                                   [color border-color]))
        (send dc draw-rectangle dx dy width height)
        (send dc set-brush old-brush)
        (send dc set-pen old-pen))
      width height))

(cc-superimpose (disk 20)
                (cellophane (rectangle/2t 100 100 #:color-1 "green") 0.5))

(cc-superimpose (disk 20)
                (cellophane (colorize (filled-rectangle 100 100) "green") 0.5))

I expected the first image this produces to show a disk under a translucent gradiented rectangle.

[rfindler]

Cellophane just sets the alpha (via set-alpha) so presumably this is
actually a racket/gui issue (and can be demonstrated via only the dc
combinator)?

[spdegabrielle]

is this still an issue? Please consider adding the label good first issue so it is findable:

Issues labeled good first issue in in Racket GitHub repositories

[rfindler]

I'm not sure if it is a good first issue. It might be for someone that knows a lot about GUI toolkits. Also, it probably is a racket/gui issue, not a pict issue (but someone would need to verify that by making a smaller program).

[soegaard]

FWIW: This modified version of rectangle/2t works as expected (I think). It simply gets the alpha value from dc and applies it to the colors before making the gradient. I am inclined to say that the bug is in `rectangle/2t`. #lang racket (require pict racket/draw) (define (rectangle/2t width height #:border-width [border-width 1] #:border-color [border-color "black"] #:color-1 [color-1 "white"] #:color-2 [color-2 "black"]) (dc (λ (dc dx dy) (define old-brush (send dc get-brush)) (define old-pen (send dc get-pen)) (define c1 (make-object color% color-1)) (define c2 (make-object color% color-2)) (define α (send dc get-alpha)) (send c1 set (send c1 red) (send c1 green) (send c1 blue) (* α (send c1 alpha))) (send c2 set (send c2 red) (send c2 green) (send c2 blue) (* α (send c2 alpha))) (define gradient (make-object linear-gradient% dx dy dx (+ dy height) (list (list 0 c1) (list 1 c2)))) (send dc set-brush (new brush% [gradient gradient])) (send dc set-pen (new pen% [width border-width] [color border-color])) (send dc draw-rectangle dx dy width height) (send dc set-brush old-brush) (send dc set-pen old-pen)) width height)) (cc-superimpose (disk 20) (cellophane (rectangle/2t 100 100 #:color-1 "green") 0.5)) (cc-superimpose (disk 20) (cellophane (colorize (filled-rectangle 100 100) "green") 0.5)) [image: image.png] Den tor. 18. jun. 2020 kl. 16.04 skrev Robby Findler < [email protected]>:

…

I'm not sure if it is a good first issue. It might be for someone that knows a lot about GUI toolkits. Also, it probably is a racket/gui issue, not a pict issue (but someone would need to verify that by making a smaller program). — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#2 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AADQXRJPEVQBR4TUTEB2TDTRXINE7ANCNFSM4BKOM7IQ> .

-- -- Jens Axel Søgaard

[rfindler]

Just to make sure I'm following: you're saying that setting the dc's alpha is not supposed to affect the brush/pen's gradient and so functions like rectangle/2t should be expected to explicitly account for that if they want to respect functions like cellophane?

The alternative would be to have cellophane explicitly adjust the gradient (if it finds one)? It does at least seem like that explicit adjustment is possible, based on the methods. (I have no idea if it is a bad idea, however!)

[soegaard]

Den tor. 18. jun. 2020 kl. 16.48 skrev Robby Findler < [email protected]>:

Just to make sure I'm following: you're saying that setting the dc's alpha is not supposed to affect the brush/pen's gradient and so functions like rectangle/2t should be expected to explicitly account for that if they want to respect functions like cellophane?

That's exactly what I thought - but now I have changed my mind. The documentation on dc<%> says: [image: image.png] So normally brush colors are blended with the correctly - but in the `rectangle/2t` example is "hidden" inside the gradient. So the problem could simply be that the gradient colors aren't adjusted when the gradient is used. Note that brushes exist independently of a drawing context. It's possible to use the same brush in different drawing contexts. Therefore the brush can't inherit an alpha value from a drawing context when it is created (which would be simpler than adjusting colors when brushes are applied). The question is where the blending happens in the source code? /Jens Axel

[soegaard]

Looking at the code of `racket/draw` I think every use of cairo_pattern_create_linear and cairo_pattern_create_radial is through the function (make-gradient-pattern cr gradient transformation) at line 890. Maybe it is enough to multiply the alpha value at line 902 with the alpha value from the drawing context? https://github.com/racket/draw/blob/ec86a7ee11f3bd2163afd9d008ef0b52e1f603a6/draw-lib/racket/draw/private/dc.rkt#L890

[soegaard]

With this as line 902 [a (* (color-alpha c) (get-alpha))]) instead of [a (color-alpha c)]) the original example results in this image: [image: image.png] The question is whether the change has some unexpected side effects? /Jens Axel Den tor. 18. jun. 2020 kl. 17.44 skrev Jens Axel Søgaard < [email protected]>:

…

Looking at the code of `racket/draw` I think every use of cairo_pattern_create_linear and cairo_pattern_create_radial is through the function (make-gradient-pattern cr gradient transformation) at line 890. Maybe it is enough to multiply the alpha value at line 902 with the alpha value from the drawing context? https://github.com/racket/draw/blob/ec86a7ee11f3bd2163afd9d008ef0b52e1f603a6/draw-lib/racket/draw/private/dc.rkt#L890

-- -- Jens Axel Søgaard

[mflatt]

I think that's almost certainly a good repair.

The only problem I see is that some existing program might rely on the alpha setting not affecting gradients (and maybe including an explicit alpha in the gradient construction to compensate). But I think the risk of breaking old programs in a significant way is small enough that it's worth fixing gradient brushes.

[soegaard]

This is the result after the [a (* (color-alpha c) (get-alpha))] change.

This is the result of the original program:

/Jens Axel
(who keeps forgetting that Github can't handle images when sent through gmail)