[Haskell-cafe] Re: Why binding to existing widget toolkits doesn't make any sense

[Peter Verswyvelen]

When I said Cairo felt rather slow, I was comparing it again fully hardware
accelerated solutions.
With Cairo I am unable to perform full smooth screen redraws of even just a
single solid rectangle, and when you are making ZUI (zoomable user
interfaces), full screen redraws are not uncommon. "Smooth" here means at
least 30 frames per second, but preferably 60 frames per second. It seems
not the number of shapes that are rendered is the bottleneck, but the amount
of pixels covered. At least that is what I noticed. I guess this is because
it is a 100% software renderer, and it might have to perform per pixel
conversion when copying to the video card, but I really don't know.

It is funny that even the oldest computers outperformed modern desktops in
some way. For example on my good old Commodore Amiga (rip) computer a text
editor existed that allowed really smooth scrolling of the text (CygnusEd),
something I haven't seen on any modern desktop. It's weird we accept the
shaky movements of gui elements on almost all operating systems... although
with the iPhone, OSX and maybe Windows 7 this will soon be over (not sure
about Linux variants, I haven't followed these).

IMO the future is fully hardware accelerated rendering on the GPU, like OpenVG.
It will take a while before it is common to see glyphs being rendered on the
GPU, but I'm sure this is all doable.

2009/1/31 Rick R <rick.richardson at gmail.com>

> Cairo is now the graphics back end for Firefox, yes? I thought moving to
> Cairo resulted in a considerable rendering speedup for FF.
>
> On Fri, Jan 30, 2009 at 6:31 PM, Peter Verswyvelen <bugfact at gmail.com>wrote:
>
>> I found Cairo rather slow, even on the fastest hardware.
>>
>> Maybe OpenVG will take off one day:
>> http://www.khronos.org/openvg
>>
>>
>> 2009/1/30 Bryan O'Sullivan <bos at serpentine.com>:
>> > Hi, Antony -
>> >
>> > It's good to see you active on here.
>> >
>> >>
>> >> It's not clear to me if the Cairo API in its current form supports
>> >> vector-level clipping or constructive area geometry, [...]
>> >
>> > The Cairo clipping API is very PostScripty; you set up a path and then
>> turn
>> > it into a clip region instead of filling it. You don't end up with a
>> > first-class value, but a manipulation of the implicit global rendering
>> > state. For CAG-style operations, http://lib2geom.sourceforge.net/ would
>> be a
>> > better bet, but FFIing to a library written in C wouldn't necessarily be
>> a
>> > real improvement over just writing a CAG library natively. I think it
>> would
>> > be true to say that you can't quite get everything you would want in one
>> > easy-to-use place, then.
>> >
>> >
>> > _______________________________________________
>> > Haskell-Cafe mailing list
>> > Haskell-Cafe at haskell.org
>> > http://www.haskell.org/mailman/listinfo/haskell-cafe
>> >
>> >
>> _______________________________________________
>> Haskell-Cafe mailing list
>> Haskell-Cafe at haskell.org
>> http://www.haskell.org/mailman/listinfo/haskell-cafe
>>
>
>
>
> --
> We can't solve problems by using the same kind of thinking we used when we
> created them.
>    - A. Einstein
>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20090131/9d3175d3/attachment.htm