
Thanks, Peter, for the paper link... I'll look at this, as it's
exactly what it sounds like I want for the future of Hieroglyph...
2009/1/31 Peter Verswyvelen
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
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
wrote: On Fri, Jan 30, 2009 at 4:25 PM, Bryan O'Sullivan
wrote: On Fri, Jan 30, 2009 at 1:11 PM, Antony Courtney
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