[Haskell-cafe] Re: Why binding to existing widget toolkits
doesn't make any sense
jefferson.r.heard at gmail.com
Sun Feb 1 18:10:38 EST 2009
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.
2009/1/31 Peter Verswyvelen <bugfact at 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
> 2009/1/31 Conal Elliott <conal at 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, ...).
>> - Conal
>> On Fri, Jan 30, 2009 at 1:56 PM, Antony Courtney
>> <antony.courtney at gmail.com> wrote:
>>> On Fri, Jan 30, 2009 at 4:25 PM, Bryan O'Sullivan <bos at serpentine.com>
>>> > On Fri, Jan 30, 2009 at 1:11 PM, Antony Courtney
>>> > <antony.courtney at 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.
>>> Haskell-Cafe mailing list
>>> Haskell-Cafe at haskell.org
>> Haskell-Cafe mailing list
>> Haskell-Cafe at haskell.org
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
More information about the Haskell-Cafe