[haiku-development] Re: Cario and Skia
- From: Simon Taylor <simontaylor1@xxxxxxxxxxxx>
- To: haiku-development@xxxxxxxxxxxxx
- Date: Fri, 24 Feb 2012 08:04:24 +0000
On 24/02/12 05:25, Jorma Karvonen wrote:
I wonder if design patterns could be used for this Cairo-Skia problem.
I was thinking about Abstract Factory.
At the Firefox/Webkit level I'm sure that's what happens - they obtain
some implementation of whatever rendering API they use. Skia and Cairo
implementations will already exist.
At the Haiku level, it really is all about giving client APIs access to
the "backbuffer" used for normal drawing. There's no fundamental reason
why it can't be as quick as the BeAPI. Currently BeAPI calls go to the
app_server where AGG renders them to the backbuffer (chunk of memory).
If the client can render directly into there using another API
(Skia/Cairo/etc) then it should be able to achieve the same performance.
As Skia/Cairo have been used (and optimised by) browsers fighting a
performance war and we avoid the cost of converting between BeAPI and
AGG it may even be faster.
On 23/02/12 21:51, Fredrik Holmqvist wrote:
> You missed the point. Drawing several invalidated regions into
> surfaces and then blitting them into the final image will kill
> performance, if the blit is in hardware or software is not relevant.
> Drawing directly into the final image was painful enough without extra
> blits, and since Cairo isn't much of a performer you are doing slow
> drawing at that.
I don't see why there will need to be any "extra blits" on top of what
would be needed with the BeAPI. It is just a case of using Skia/Cairo to
render to the backbuffer rather than AGG in the app server.
Cairo performance isn't bad, as far as I know. It was simply because FF
were fighting a performance battle on canvas demos, wanting to push 60
FPS. Microsoft designed a nice accelerated 2D API, probably with IE in
mind as the main user. Cairo even included a backend for that, but as
the accelerated drawing was so fast, the conversion between FF -> Cairo
-> Direct2D accounted for a significant part of the cost. It's not that
Cairo is slow, but it just turned out that Direct2D was a better match
for the internal firefox api, so they made a wrapper that was more
suited to that. You certainly can't see the fact FF dropped Cairo as any
sort of indication that it would be slower than a BeAPI -> app_server
AGG backend.
Currently FF still uses lots of Cairo in fallback cases, so it would
still be necessary (along with being the easiest route) for a port.
I'm going to try getting both Skia and Cairo going. I still haven't done
all the research required, but it seems like Skia's surface format will
need conversion for the app_server. I think Cairo should support the
same format used by the app_server internally which may give it a
performance edge. We'll just have to experiment.
Other related posts:
