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@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@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@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@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



--
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@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe