Hi!
I've been reading code this weekend trying to figure out a way to achieve
the desired GPU render on screen for the Synfig Studio canvas windows.
The current renderer works like this:
The WorkArea class is where all the rendering is produced. It is a class
derived from Duckmatic (the one that handles the ducks and similar things
that are drawn on the canvas) and also it is a Gtk::Table derived.
WorkArea (as a container type it is) has several Gtk widgets inside to
perform the visual interface. Between others, there is a Gtk::DrawingArea
where the ducks and the actual rendered layers are displayed.
On the other hand, there is a class called WorkAreaRenderer that is the
root class for all the derived rendered (Canvas renderer, BBox renderer,
Grid renderer, Ducks renderer, etc). Each renderer receives a
Gtk::DrawingArea and an expose rectangle of that drawing area and then
performs the drawing operations on the Drawing Area
There is a third component that plays here. Derived from Target_Tile or
from Target_Scanline, there are two groups of targets for the workarea.
Two are asynchronous and other two are synchronous.
Target_Scanline
┃
┣━━━ AsyncTarget_Scanline
┃
┗━━━ WorkAreaTarget_Full
Target_Tile
┃
┣━━━ AsyncTarget_Tile
┃
┗━━━ WorkAreaTarget
They (like all targets) takes a time, a context and a render description
and renders the context to a certain surface.
For the onionskin feature and for the tile render feature, both targets
groups uses an array of pixbufs to store the rendered context and its
potential tiles or onionskins. So finally the rendered surfaces are stored
in the pixbufs.
Those three components (Drawing Area, Targets and Renderers) are handled by
the work area this way:
Using the gtk loop main cycle, it adds a function that at regular intervals
updates workarea by calling the renderers to do its drawing operations over
the Drawing Area.
On the other hand there is one similar asynchronous thread where the canvas
is rendered to the mentioned pixbufs.
The canvas renderer just copies the pixbufs (result of the sync or
asynchronous renderers) to the drawing area. The renderers are called in
order based on its prioirty. Canvas renderer has highest priority.
Thanks to the work of Nikitakit, all the renderers currently uses Cairo
operations to perform those drawings (included the copy of the pixbuf to
drawing area).
The problem comes when I want to include direct screen drawing for the
surfaces used on the renderers. This would break out all the current render
system: a context is rendered into memory and then a set of renderers
transfer the result to the screen.
I would eventually redo all the render system with a new method, that don't
use a Drawing Area but a device (the Screen) as target.
Notice that, the render time of the canvas can be much longer than the
render time of the rest of the renderers so it might happen that the canvas
render, when it draws to the screen, might erase or destroy the work of the
other renderers (ducks for example).
In the current system, the longer render time of the canvas doesn't matter
because the canvas renderer would use what is ready in the pixbuf (even if
it is not complete) and won't interfere with the ducks or the grid because
all they are composed in the right order.
So my problem is, when I draw directly to the screen, the difference of the
render times might make interfere one renderer to other.
How is this solved in the current applications? If I render to memory like
it is now how can I gain the benefit of the gl rendering (via GPU)?
The problem is so big that I don't know where to start.
Any advice?
--
Carlos
http://synfig.org
------------------------------------------------------------------------------
LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access PCs and mobile devices and provide instant support
Improve your efficiency, and focus on delivering more value-add services
Discover what IT Professionals Know. Rescue delivers
http://p.sf.net/sfu/logmein_12329d2d
_______________________________________________
Synfig-devl mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/synfig-devl
