Cool! Looking forward to it. On Mon, Feb 2, 2009 at 12:10 AM, 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