2012/12/10 Carlos López González <[email protected]>: > 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? >
Hi, Carlos! Maybe my question is silly, but why you want to draw directly on the screen? Are there any chance to draw on cairo-gl surface? http://stackoverflow.com/questions/6105948/how-to-create-a-cairo-gl-surface-under-gtk K. -- http://morevnaproject.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
