Gradient #136

jeffreyrosenbluth · 2013-11-11T21:28:37Z

I think this and the other gradient branches are ready to merge.

bergey · 2013-11-13T02:25:15Z

I still think that users should not need to change between fc and fcT when switching backends. It's moderately annoying in code that uses gradients, and very annoying in code that only uses solid colors.

As a concrete proposal: can we have the fc function add a FillColor attribute and a FillTexture attribute? I expect that all backends will honor exactly one of those. It does change the type of fc (adding R2 constraint), but I don't expect that to break much code in the wild.

I haven't tried this. I think it provides semantics for backends that don't handle gradients, without requiring duplicate code in every backend. (I know we debated those questions in #9).

bergey · 2013-11-13T02:30:05Z

src/Diagrams/TwoD/Attributes.hs

+import           Data.Semigroup
+
+-- | A stop is (color, proportion, opacity)
+type GradientStop = (SomeColor, Double, Double)


a) Can this be a real type instead of an alias?
b) Do we really need SomeColor? Would AlphaColor work as well?
c) Since SomeColor / AlphaColor already has opacity, do we need another double about opacity?

a) Do you mean data GradientStop = GradientStop SomeColor Double Double? Any reason for the preference?

@byorgey suggested b & c as well I don't have a strong preference either way. My intention was to be consistent with FillColor and LineColor.

IIUC, type doesn't provide any type safety; any (SomeColor, Double, Double) will do. Untyped Doubles make me nervous---they could reperesent anything.

I don't understand the SomeColor in FillColor either. :)

jeffreyrosenbluth · 2013-11-13T02:39:50Z

@bergey re: fc and fcT - I like your suggestion , let me look at the code and see if this can work.

fryguybob · 2013-11-13T03:16:42Z

src/Diagrams/TwoD/Attributes.hs

+
+-----------------------------------------------------------------------------
+-- |
+-- Module      :  Diagrams.Attributes


Should be: "Module : Diagrams.TwoD.Attributes".

yes, thanks

fryguybob · 2013-11-13T13:52:25Z

You mention supporting backends that do not support gradients. Can you elaborate on what API we would end up with if we went ahead and broke all backends? Is there a clean way to have attributes that do not care what vector-space they live in work together with attributes that do? Textures appear to me to carry the meaning of functions from some space to a color (f :: Color c => R2 -> c for instance). Can we simply do the appropriate projection to move from one space to another? I know in 3D we also care about lighting but I think this can be nicely handled as a separate issue.

jeffreyrosenbluth · 2013-11-13T15:00:59Z

If we broke all backends, then SomeColor would be replaced by the more general Texture which includes SomeColor, LGradient, RGradient and eventually patterns. I haven't tried to generalize Texture to arbitrary vector spaces. I got the impression from @bergey that it might not be useful for 3D? Do you think it is important?

bergey · 2013-11-13T15:13:55Z

@jeffreyrosenbluth , please correct me if I'm wrong. If we completely replace FillColor with FillTexture, all (2D) Backends need to change, but user code can stay the same---continue to use fc. Backends which do not support gradients need some way to fallback to a solid color. That's clearly better than requiring some user code to switch to fcT. But see my proposal upthread.

I thought the point of implementing gradients is that backend libraries already support them. That is, SVG can represent them directly, and cairo does something sensible (?). I agree that R2 -> color is the general form. Does that form commit us to rasterizing ourselves? I think @jeffreyrosenbluth is planning (hoping?) to implement general textures (image maps), at which point the gradient constructors become basically an optimization.

In R3 it's worse. I think POVRay (our only 3D Backend right now) only supports 2D textures surface mapped (not sure how) to the objects. That's pretty common, I think, especially for non-raytracing implementations. Parametric 3D textures are really nice, but what backend would we target? I'd love to have a native Haskell raytracer or a custom OpenGL shader, but I think either is a long way off.

byorgey · 2013-11-13T15:21:42Z

It's been a long time since I've used POVRay, but I'm quite sure it has support for "solid", i.e. parametric 3D, textures.

bergey · 2013-11-13T15:22:55Z

@byorgey Ooh. I'll look harder in the docs, then. Thanks!

fryguybob · 2013-11-13T15:24:39Z

Specifically I think the breaking change is replacing SomeColor in:

newtype FillColor = FillColor (Recommend (Last SomeColor))

With a Texture sum type. At which point it should be named FillTexture. As @bergey points out I don't think this changes any user code (It might change query code but we don't have that yet :D). I think this is a worthwhile change to consider. The question for me is can we generalize the vector-space nicely or not. The R2 -> Color is just the denotation for textures, so that doesn't force us to rasterize, but it does give us the semantics of what a correct implementation means.

I'm pretty sure PovRay can handle a 3d texture and not just a texture as a surface, I'll look into it.

jeffreyrosenbluth · 2013-11-13T16:04:46Z

@bergey is right about the Backends needing to change if we completely replace FillColor with FillTexture and the user code can remain unchanged. But I think his proposal should be a good work around.

@fryguybob Re, generalizing from R2 to v. I'm not sure if we should try to do this now. My instinct is to get it to a point where we are happy with the 2D implementation and then think about generalizing.

byorgey · 2013-11-14T03:00:27Z

I do like the solution of having e.g. lc apply both line color and line texture attributes. Being able to do this sort of thing is a nice benefit of having our Styles be heterogeneous collections of arbitrary attributes, of which backends only need to handle some subset (rather than e.g. a fixed sum type of attributes).

jeffreyrosenbluth · 2014-04-16T00:50:40Z

If someone would put this through some tests with cairo and svg then we can add some documentation and merge.

byorgey · 2014-04-18T01:52:42Z

src/Diagrams/TwoD.hs

@@ -77,6 +77,7 @@ module Diagrams.TwoD
       , strokeLocTrail, strokeLocT, strokeLocLine, strokeLocLoop
       , FillRule(..), fillRule
       , StrokeOpts(..), vertexNames, queryFillRule
+       , splitFills


What's the reason for re-exporting this from Diagrams.TwoD? I think I intentionally did not re-export it because it is useful only to backend writers, who can import Diagrams.TwoD.Attributes if they need it; there's no need to export it from Diagrams.Prelude.

Your right, I'll take it out

byorgey · 2014-04-18T02:08:45Z

This is looking good to me.

byorgey · 2014-04-18T02:17:54Z

src/Diagrams/TwoD/Attributes.hs

+data FillLoops v = FillLoops
+
+instance Typeable v => SplitAttribute (FillLoops v) where
+  type AttrType (FillLoops v) = FillColor


Ugh, I think this now needs to consider both FillColor and FillTexture, but the way I have it set up it can only handle doing one at a time. =(

One solution I suppose would be to make a second function akin to splitFills but acting on FillTexture. It's just a bit annoying to have to do two passes, but it should only be a few extra lines of code (copy lines 551-566 here and change a few things).

Sorry I don't have better answers to some of the line notes. Some of this
code was written as long as 6 months ago, so I don't remember exactly what
I was thinking at the time. I'll try to look into some the your questions
more deeply this weekend.

On Thu, Apr 17, 2014 at 10:17 PM, Brent Yorgey notifications@github.comwrote:

In src/Diagrams/TwoD/Attributes.hs:

+-- | A synonym for 'fillColor', specialized to @'Colour' Double@
+-- (i.e. opaque colors). See comment after 'fillColor' about backends.
+fc :: (HasStyle a, V a ~ R2) => Colour Double -> a -> a
+fc = fillColor
+
+-- | A synonym for 'fillColor', specialized to @'AlphaColour' Double@
+-- (i.e. colors with transparency). See comment after 'fillColor' about backends.
+fcA :: (HasStyle a, V a ~ R2) => AlphaColour Double -> a -> a
+fcA = fillColor
+------------------------------------------------------------
+
+data FillLoops v = FillLoops
+
+instance Typeable v => SplitAttribute (FillLoops v) where

type AttrType (FillLoops v) = FillColor

Ugh, I think this now needs to consider both FillColor and FillTexture,
but the way I have it set up it can only handle doing one at a time. =(

One solution I suppose would be to make a second function akin to
splitFills but acting on FillTexture. It's just a bit annoying to have to
do two passes, but it should only be a few extra lines of code (copy lines
551-566 here and change a few things).

—
Reply to this email directly or view it on GitHubhttps://github.com//pull/136/files#r11762174
.

No worries. I may have some time to help out as well.

jeffreyrosenbluth · 2014-04-20T16:14:19Z

I think this gradient branches are ready to merge

bergey · 2014-04-23T00:20:35Z

+1

Gradient

jeffreyrosenbluth added 12 commits October 24, 2013 20:08

initial commit

6bb1f53

added TwdD.Attributes

3be8bdf

ready for testing with backend

7c38e90

update exports for gradients

ce57c67

linear gradient

5564200

transform gradient

fe1e279

work in progress

c873735

more progress

1f52aac

there is hope

f546b68

cleaning up linear gradients

88944c6

start radial gradients

933a4dd

begin stroke gradients

977ad18

bergey reviewed Nov 13, 2013
View reviewed changes

fryguybob reviewed Nov 13, 2013
View reviewed changes

jeffreyrosenbluth added 2 commits November 13, 2013 14:02

bergeys proposal

019990d

appease Travis

f7226b4

jeffreyrosenbluth added 4 commits November 14, 2013 11:05

merged wtih master

685ed07

haddock docs

6317c61

export more gradient functions

3b4eb9d

for Travis

8a372a4

jeffreyrosenbluth added 7 commits November 16, 2013 15:40

generalize radial gradients to annulli

047664f

set default line texture

4ab2b26

merge with master

420399b

accomodate units changes

57f494d

woring with svg

36935f2

complete Color instances

f46b8b0

fix comment

f1a8217

update comments and defaults

bb2597c

byorgey reviewed Apr 18, 2014
View reviewed changes

jeffreyrosenbluth added 3 commits April 18, 2014 14:37

minor edits

7261c63

splitColorFills, splitTextureFills

6f236db

added gradient tests

2556c12

byorgey added a commit that referenced this pull request Apr 23, 2014

Merge pull request #136 from diagrams/gradient

d7f75fd

Gradient

byorgey merged commit d7f75fd into master Apr 23, 2014

byorgey deleted the gradient branch April 23, 2014 00:51

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Gradient #136

Gradient #136

jeffreyrosenbluth commented Nov 11, 2013

bergey commented Nov 13, 2013

bergey Nov 13, 2013

jeffreyrosenbluth Nov 13, 2013

bergey Nov 13, 2013

jeffreyrosenbluth commented Nov 13, 2013

fryguybob Nov 13, 2013

jeffreyrosenbluth Nov 13, 2013

fryguybob commented Nov 13, 2013

jeffreyrosenbluth commented Nov 13, 2013

bergey commented Nov 13, 2013

byorgey commented Nov 13, 2013

bergey commented Nov 13, 2013

fryguybob commented Nov 13, 2013

jeffreyrosenbluth commented Nov 13, 2013

byorgey commented Nov 14, 2013

jeffreyrosenbluth commented Apr 16, 2014

byorgey Apr 18, 2014

jeffreyrosenbluth Apr 18, 2014

byorgey commented Apr 18, 2014

byorgey Apr 18, 2014

jeffreyrosenbluth Apr 18, 2014

byorgey Apr 18, 2014

jeffreyrosenbluth commented Apr 20, 2014

bergey commented Apr 23, 2014

Gradient #136

Gradient #136

Conversation

jeffreyrosenbluth commented Nov 11, 2013

bergey commented Nov 13, 2013

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

jeffreyrosenbluth commented Nov 13, 2013

Choose a reason for hiding this comment

Choose a reason for hiding this comment

fryguybob commented Nov 13, 2013

jeffreyrosenbluth commented Nov 13, 2013

bergey commented Nov 13, 2013

byorgey commented Nov 13, 2013

bergey commented Nov 13, 2013

fryguybob commented Nov 13, 2013

jeffreyrosenbluth commented Nov 13, 2013

byorgey commented Nov 14, 2013

jeffreyrosenbluth commented Apr 16, 2014

Choose a reason for hiding this comment

Choose a reason for hiding this comment

byorgey commented Apr 18, 2014

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

jeffreyrosenbluth commented Apr 20, 2014

bergey commented Apr 23, 2014