FBO equivalent

374 views
Skip to first unread message

Shawn Riordan

unread,
Jul 9, 2016, 10:27:15 PM7/9/16
to skia-discuss
I am thinking of rewriting an app in Skia.  Currently, the app breaks the frame window up into a bunch of panels.  Where each is handled as an OpenGL frame buffer object.

If I were writing this in Skia CPU, using what I know so far, I would just make a bunch of n32 raster surfaces for each panel.  Then the main draw() method would ask each panel for it's SkImage and then draw them all to the main view's surface / canvas.

But I would like to do GPU Skia.  What is the best method for handling a scenario like this?  What is the Skia GPU version of an OpenGL frame buffer object?

Mike Reed

unread,
Jul 10, 2016, 11:07:06 AM7/10/16
to skia-d...@googlegroups.com
How will you get each panel/render-target to the window for compositing?

If you want to pre-allocate the render-targets, use SkSurface::MakeFromBackendTexture(). 

--
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 https://groups.google.com/group/skia-discuss.
For more options, visit https://groups.google.com/d/optout.

Shawn Riordan

unread,
Jul 11, 2016, 12:30:35 AM7/11/16
to skia-discuss
"How will you get each panel/render-target to the window for compositing?"

That is sort of my question to you?  For any normal surface, I would ask the surface for an image snapshot.  And then draw that image to the main surface.  But that would involve a copy operation that seems unnecessary.  Is there a better way to do it, using a surface returned from SkSurface::MakeFromBackendTexture()?

Also, I was poking around and noticed the Artist and Layout classes.
Might they be a better way to implement the scenario I am shooting for? (where the frame window is broken up into a bunch of arbitrary panels)

There isn't a lot of (any) examples of how either of those classes should be used.

Brian Salomon

unread,
Jul 11, 2016, 9:31:21 AM7/11/16
to skia-discuss
You can create SkSurfaces from externally created texture or FBO ids. For FBOs use MakeFromBackendRenderTarget and for textures use MakeFromBackendTexture. You draw to the canvas's surface and call SkCanvas::flush() when finished. After flush() returns all GL calls related to the canvas drawing have been issued to the underlying OpenGL context. You don't need to snap an image. You just do whatever compositing or custom rendering steps you need in OpenGL (if any) and then swap buffers. Just be aware that Skia assumes control of OpenGL state. After you make your own OpenGL calls and before calling back into Skia call GrContext::resetContext() to let Skia know that OpenGL state may have changed.

Shawn Riordan

unread,
Jul 12, 2016, 12:34:25 AM7/12/16
to skia-discuss
"You can create SkSurfaces from externally created texture or FBO ids"

I kind of hoped to keep the whole thing purely Skia. For the sake of Agnosticism.
Thought there might already be "traditional" ways to handle this sort of thing.

Shawn Riordan

unread,
Jul 12, 2016, 1:36:31 AM7/12/16
to skia-discuss
I don't mean to shit on your suggestion.  After some thought, it has its attractions.  I mean, I could keep my existing app's OpenGL code and just switch to Skia at the last moment.   Would there be any performance issues regarding text? Like loading glyph textures and then dropping them on every draw()?

One of the main reasons I wanted to switch to Skia, was the uniformity and quality of the text rendering.  Currently, I am using Cinder.  Which is an OpenGL wrapper and very nice in its own way.  But the text rendering leaves a lot to be desired.  For example, a 16 pixel tall font renders completely differently on Mac than it does on Windows.  While Skia seems consistent.  Not to mention all the great 2D draw() methods that Skia has.




On Monday, July 11, 2016 at 6:31:21 AM UTC-7, Brian Salomon wrote:

Brian Salomon

unread,
Jul 12, 2016, 9:09:40 AM7/12/16
to skia-discuss
As long as you keep your GrContext around everything in it's cache (glyphs, images, etc) sticks around. If you want to use Skia for the panel compositing step then you'd have to somehow get the FBO ID for the platform window's backing store (probably FBO 0) and wrap that using SkSurface using MakeFromBackendRenderTarget. You can then use SkSurface::MakeRenderTarget to have Skia create the FBOs for each panel. When you want to composite the panels you snap images from the panel surfaces and draw them to the SkSurface made around the window's backing store, call flush on the window's surface's canvas and then whatever the native swapbuffers is. The snapped images for the panels shouldn't trigger a copy so long as you drop your refs to the images before drawing to the panels again.

Shawn Riordan

unread,
Jul 12, 2016, 11:17:59 PM7/12/16
to skia-discuss
How about the Artist or Layout classes?  Would they do the behavior I am looking for?
How are they implemented, under the hood?

Mike Reed

unread,
Jul 13, 2016, 8:21:58 AM7/13/16
to skia-d...@googlegroups.com
Those are just helpers for the view hierarchy, and not related to gpu rendering at all. Easy to grep the sources to see how they are implemented.
Reply all
Reply to author
Forward
0 new messages