xlib or gtk (or any other option) with skia on linux

[athos bacchiocchi]

I'm using skia to draw some custom UI elements in c++ on android, and I'd like to port some of them to gnu/linux now that I'm starting some projects there. Here are the options I am considering after some research:

1) XLIB

Less layers and overhead to get what I need (I would just need to link my "custom windows" event handling with x and use skia to draw the interface). More complicated to code, and I don't know what will happen on the distributions that will abandon X for things like wayland or mir. As far as I understand, the SampleApp is using this method (through SkWindow), but it's not easy to follow, is there any bare-minimum example?

3) GTK+ (through gtkmm)

It's simple and documented, and I could use gtk widgets as well if I ever need to. For my custom views I guess I would have to use a Drawing Area Widget and use Skia instead of Cairo for the drawing. But how could I get a drawing context to use with skia from gtk+ ?

Does anyone have some advice, experience or any other option to share? 

athos

[Mike Reed]

We don't have a clean porting guide for adapting Skia to window managers. SampleApp's glue through SkWindow is pretty old and fragmented. It only exists for that test app, and is not officially supported.

However, there is a very clean way to create a Skia drawing context (surface, canvas):

SkImageInfo info = ... // width, height, pixel format, etc.

void* pixels = ... // allocate temporary memory, or point to the window's buffer

size_t rowBytes = ... // must be >= info.minRowBytes()

SkSurface* surface = SkSurface::NewRasterDirect(info, pixels, rowBytes);

SkCanvas* canvas = surface->getCanvas();

... // draw into the canvas

canvas->flush();

// now you can read/copy the pixels to your window

Alternatively, if you have a GL context already create, you can create a surface that will draw directly into that using SkSurface::NewRenderTargetDirect(...)

--
You received this message because you are subscribed to the Google Groups "skia-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to skia-discuss...@googlegroups.com.
To post to this group, send email to skia-d...@googlegroups.com.
Visit this group at http://groups.google.com/group/skia-discuss.
For more options, visit https://groups.google.com/groups/opt_out.

[athos bacchiocchi]

Thanks Mike for your suggestions, I'm leaning toward the GTK approach, so I'll look for a way to get the window's raw buffer pointer to be fed to a new SkSurface. I'm actually using a similar approach on android, but with a skdevice and a skbitmap wrapping the native buffer, something like this:

ANativeWindow_lock(window,&buffer, NULL);
// ... get pixelFormat and pixelBytes ...
bitmap.setConfig(pixelFormat,buffer.width,buffer.height,pixelBytes*buffer.stride);
bitmap.setPixels(buffer.bits);
device = new SkDevice(bitmap);
canvas = new SkCanvas(device);
// ... draw to the canvas and unlock the native window ...

What's the advantage of using SkSurface over this SkDevice+SkBitmap?

athos

[Mike Reed]

Advantage: nothing concrete yet, but we are deprecating SkDevice, but SkBitmap+SkCanvas should be supported for a while.

--