Oh, and by functional, I mean that it isn't a complete re-wrapping of the library, not that you have IO creeping in all over the place. Pardon my unclearness.
On Sun, Feb 1, 2009 at 6:10 PM, Jeff Heard <jefferson.r.he...@gmail.com> wrote: > Everyone, I'll be releasing Hieroglyph this week. Right now I'm unit > testing and I've been out of town this past weekend without much > opportunity to work on it. It's not yet a complete functional > re-working of Cairo -- for instance, right now patterns aren't > supported, and Pango layouts aren't either -- but it should become so. > I'll also be forking Hieroglyph to develop a complete, > pure-functional 2D graphics toolkit. > > -- Jeff > > 2009/1/31 Peter Verswyvelen <bugf...@gmail.com>: >> Hi Conal, >> Do you have any links to this interesting work of Jefferson Heard? Blogs or >> something? I failed to Google it, I mainly found his OpenGL TrueType >> bindings on Hackage and his >> beautiful http://bluheron.europa.renci.org/docs/BeautifulCode.pdf >> Regarding semantics, modern GPUs are able to render 2D graphics (e.g. filled >> or stroked curves) as real functions / relations; you don't need fine >> tessellation anymore since these computational monsters have become so fast >> that per pixel inside / outside testing are feasible now. It's basically a >> simple form of real-time ray-tracing :) A quick search revealed another >> paper using these >> techniques http://alice.loria.fr/publications/papers/2005/VTM/vtm.pdf >> Cheers, >> Peter >> 2009/1/31 Conal Elliott <co...@conal.net> >>> >>> Hi Antony, >>> >>>> >>>> Hopefully some enterprising Haskell hacker will wrap Cairo in a nice >>>> purely functional API. >>> >>> Jefferson Heard is working on such a thing, called Hieroglyph. Lately >>> I've been helping him simplify the design and shift it toward a clear, >>> composable semantic basis, i.e. "genuinely functional" (as in the Fruit >>> paper), meaning that it can be understood & reasoned about in precise terms >>> via model that is much simpler than IO. >>> >>> In the process, I realized more clearly that the *very goal* of making a >>> purely functional wrapper around an imperative library leads to muddled >>> thinking. It's easy to hide the IO without really eliminating it from the >>> semantics, especially if the goal is defined in terms of an IO-based >>> library. Much harder, and I think much more rewarding, is to design >>> semantically, from the ground up, and then figure out how to implement the >>> elegant semantics with the odds & ends at hand (like Cairo, OpenGL, GPU >>> architectures, ...). >>> >>> Regards, >>> >>> - Conal >>> >>> On Fri, Jan 30, 2009 at 1:56 PM, Antony Courtney >>> <antony.court...@gmail.com> wrote: >>>> >>>> On Fri, Jan 30, 2009 at 4:25 PM, Bryan O'Sullivan <b...@serpentine.com> >>>> wrote: >>>> > On Fri, Jan 30, 2009 at 1:11 PM, Antony Courtney >>>> > <antony.court...@gmail.com> >>>> > wrote: >>>> >> >>>> >> A 2-D vector graphics library such as Java2D ( or Quartz on OS/X or >>>> >> GDI+ on Windows ) supports things like computing tight bounding >>>> >> rectangles for arbitrary shapes, hit testing for determining whether a >>>> >> point is inside or outside a shape and constructive area geometry for >>>> >> shape compositing and clipping without dropping down to a raster >>>> >> representation. >>>> > >>>> > These are the kinds of capabilities provided by Cairo, which is very >>>> > pleasant to use (PDF-style imaging model) and quite portable. There are >>>> > already Cairo bindings provided by gtk2hs, too. >>>> > >>>> >>>> Hi Bryan, >>>> >>>> Nice to hear from you! Been a while... >>>> >>>> Just had a quick look and it does indeed appear that Cairo now >>>> supports some of the features I mention above (bounds calculations and >>>> hit testing). Cairo has clearly come a long way from when I was last >>>> working on Fruit and Haven in 2003/2004; back then it looked like it >>>> only provided a way to render or rasterize vector graphics on to >>>> bitmap surfaces and not much else. >>>> >>>> It's not clear to me if the Cairo API in its current form supports >>>> vector-level clipping or constructive area geometry, and it looks like >>>> the API is still pretty render-centric (e.g. is it possible to obtain >>>> the vector representation of rendering text in a particular font?). >>>> That might make it challenging to use Cairo for something like the >>>> Haven API, but maybe one can live without that level of generality. >>>> >>>> In any case: delighted to see progress on this front! Hopefully some >>>> enterprising Haskell hacker will wrap Cairo in a nice purely >>>> functional API. >>>> >>>> -Antony >>>> _______________________________________________ >>>> Haskell-Cafe mailing list >>>> Haskell-Cafe@haskell.org >>>> http://www.haskell.org/mailman/listinfo/haskell-cafe >>> >>> >>> _______________________________________________ >>> Haskell-Cafe mailing list >>> Haskell-Cafe@haskell.org >>> http://www.haskell.org/mailman/listinfo/haskell-cafe >>> >> >> >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe@haskell.org >> http://www.haskell.org/mailman/listinfo/haskell-cafe >> >> > _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
