[haiku-development] Re: Cario and Skia
- From: Simon Taylor <simontaylor1@xxxxxxxxxxxx>
- To: haiku-development@xxxxxxxxxxxxx
- Date: Thu, 23 Feb 2012 19:20:15 +0000
On 23/02/12 18:33, Adrien Destugues wrote:
Le 23/02/2012 19:20, Simon Taylor a écrit :
I'm planning on keeping the abstraction very low level - just wrap
some memory as a surface, and not support concurrent BeAPI drawing
access. There will be some investigation required as to the quickest
way to get those surfaces into the app_server, but hopefully if there
is any work required there it could be shared between Cairo and Skia
and any other client-side rendering libraries.
>
You can use either BDirectWindow, set a background BBitmap on a BView,
or use an overlay.
Remember that working that way instead of using BeAPI and the app_server
backend leads to :
* code duplication (all the graphics algorithms are in the app, while we
have working ones in the app_server)
Unfortunately *all* algorithms are not already in the app; SVG/CSS etc
include some line dash styles, fill modes, compositing operations, etc,
etc which are not directly supported by the BeAPI. Sure, you can
probably build the line styles out of individual BeAPI draw line calls,
and emulate the others with some manual BBitmap.bits() hacking - but
that would still need a lot of custom code to get full standards
support, and as it's a moving target we don't have the manpower to keep up.
* integration problems (you can draw on a BBitmap and a BDirectWindow
using the BeAPI, but it's not as good as the usual way)
Indeed, mixing and matching client drawing and normal app-server drawing
will be problematic, but the driving reason for this is to support
large, fast-moving code basis for which no native Haiku backend is
available. Thus I expect such views to only be updated by the
client-side API.
It feels just like the way Linux is working : while X11 has support for
drawing lines, curves, and so on, everyone just open a window and do
their own stuff in it. This makes things like a remote X11 session or a
remote app_server slower than needed (they need to carry the whole
picture over the network, instead of just the drawing commands). So it
will never be as good as a native implementation.
Agreed there are some downsides, especially as far as network clients
go. But that is in the far-off future. In the same future, imagine a
BSkiaView that the app-server is aware of, and in network mode will
forward Skia calls on to the client...
Still, here's the current situation with Webkit:
Webcore gfx interface [1] -> Haiku native backend [2] -> BeAPI drawing
calls [3] -> app_server [4] -> AGG [5]
[1] Fast moving interface
[2] Incomplete and not up-to-date
[3] Missing some functions required for full standards compliance, which
would need to be emulated
[4] Separate process - adds some overhead for each primitive drawn
[5] Probably contains the missing bits mentioned in 3, but they're not
exposed through the BeAPI. In the end, just renders into a chunk of memory
And here's how it could be:
Webkit -> Skia/Cairo [6] -> Chunk of memory [7] -> app_server [8]
[6] Kept up to date with Webkit by other projects
[7] Small, stable, interface - minimal maintenance burden
[8] Might need a new interface (shared memory?) to efficiently composite
with BeAPI-drawn BViews
Other related posts:
