Question about rendering
Hi there,
I'm having a little bit of trouble understanding the code. Maybe someone can give me a fast explanation of this.
From my point of view Inkscape should have to type of renderers:
- a fast and optimized one (maybe not necessarly an exact one) for realtime rendering. kind of a WYSIWYG renderer for when modifying on screen - a slow but precise renderer for getting a print-ready, camera-ready or even video/film-ready, hi-res,...
These two renderers should have a common API (primitive drawing commands proper to rasterized images (points, lines and filled triangles)) in order to be able to extend this idea to other renderers (maybe someone comes up with a better antialiasing algorithm or a better renderer, or even a different buffer type result (hexagonal pixel buffers,...).
I know that the fast renderer might be a bit harder since it must be able to only draw changes, but there must be a way of dealing with this.
I'm asking this, because I would like to propose the "Creation of a shader (modifications at rendering level) language for vector images" as a Summer of Code project. Me as a student am interested in this idea. Seeing the deadlines approaching fast I would appreciate quick feedback and maybe mentor volunteers.
Thanks to all
-- ricard http://www.ricardmarxer.com
On Wed, 19 Apr 2006 16:00:14 +0200, "Ricard Marxer Piñón" <ricardmp@...400...> wrote:
Hi there,
I'm having a little bit of trouble understanding the code. Maybe someone can give me a fast explanation of this.
From my point of view Inkscape should have to type of renderers:
- a fast and optimized one (maybe not necessarly an exact one) for
realtime rendering. kind of a WYSIWYG renderer for when modifying on screen
- a slow but precise renderer for getting a print-ready, camera-ready or
even video/film-ready, hi-res,...
These two renderers should have a common API (primitive drawing commands proper to rasterized images (points, lines and filled triangles)) in order to be able to extend this idea to other renderers (maybe someone comes up with a better antialiasing algorithm or a better renderer, or even a different buffer type result (hexagonal pixel buffers,...).
I know that the fast renderer might be a bit harder since it must be able to only draw changes, but there must be a way of dealing with this.
This seems to be lumping together an awful lot of different separate concerns.
At the lowest level, we've simply got a rasterizer which renders polygons onto a buffer, filled with a pattern/texture, as well as some supplementary effects like stroking paths. That's handled via libnr/livarot at the moment. Long-term, we want to use pixman/cairo instead. This would be where the common drawing API.
On top of this, we've got a retained-mode API which remembers the scene graph and can in principle do incremental/differential rendering. For example, if only part of a shape needed painting, this layer would be responsible for extracting a subset of its outline to pass on to the lower-level layer. Right now this is handled by NRArena, which is actually pretty dumb and unoptimized. But that's where the "only draw changes" bits would belong.
From a broad perspective, this is not too different from the architecture of many 3d graphics engines.
I'm not sure where the shader-based stuff belongs in all this -- it sounds like the sort of thing that would go in a cairo backend (glitz, maybe?), hidden behind the cairo API.
-mental
On 4/19/06, Ricard Marxer Piñón <ricardmp@...400...> wrote:
From my point of view Inkscape should have to type of renderers:
- a fast and optimized one (maybe not necessarly an exact one) for realtime
rendering. kind of a WYSIWYG renderer for when modifying on screen
- a slow but precise renderer for getting a print-ready, camera-ready or
even video/film-ready, hi-res,...
Xara has proven that it's possible to have one renderer which is fast enough for complex drawings and is good at any resolution. So I don't think we should consider investing into two renderers. Besides, in SVN you have the Outline mode which is almost like your "fast and inexact" renderer :)
These two renderers should have a common API (primitive drawing commands proper to rasterized images (points, lines and filled triangles)) in order to be able to extend this idea to other renderers (maybe someone comes up with a better antialiasing algorithm or a better renderer, or even a different buffer type result (hexagonal pixel buffers,...).
And a well-defined API is certainly a good thing to have, regardless of anything else. Indeed we have at least one renderer switch ahead...
I'm asking this, because I would like to propose the "Creation of a shader (modifications at rendering level) language for vector images" as a Summer of Code project. Me as a student am interested in this idea. Seeing the deadlines approaching fast I would appreciate quick feedback and maybe mentor volunteers.
As you know, SVG has filters, which we need to implement. That has higher priority for us because it's a standard SVG feature and because they provide basic and very needed functions (such as blur, various composition modes, etc.) So I would suggest that you look into implementing these first. If you're willing, I could be your mentor. Later perhaps the same mechanism can be used to implement generic shaders (though SVG 1.1 provides only a fixed set of filters).
-- bulia byak Inkscape. Draw Freely. http://www.inkscape.org
On 4/19/06, bulia byak wrote:
Later perhaps the same mechanism can be used to implement generic shaders (though SVG 1.1 provides only a fixed set of filters).
That said, how exactly good relations do Inkscape developers have with SVG team to push more features helpful for illustrators? A while ago I tried talking in SVG list about more types of gradient fills and soon I ended up with no replies.
Alexandre
I agree that maybe there's no need of two separate renderers, at least at this point. Using the 'Outline mode' might be enough to speed up things.
And I guess that an advanced rasterizer, with computational expensive statistical antialiasing and other such features could be a completly separate project.
The idea of shaders that I try to present is quite different from the filters in the SVG 1.1 spec.
From what I understand SVG 1.1 filters are purley pixel-buffer to
pixel-buffer transformations. Although they are defined to be applied to individual vectorial objects. This is a good idea and a good SoC project. But my interest for pixel transformations is not that big as for vector and geometric transformations.
The idea of shaders would have to do with being able to have a dash stroke created with a very simple shader language, and in the same way be able to emulate the brush of a pen, penci and others using vector to vector and vector to pixel transformations at the rasterizer level. I know that my idea is not yet defined, but maybe with the help of a mentor, I get things much clearer (I only have one year of experience with vector graphics!!). I only have a first idea of the stroke shader part, I think the fill part could be very much like the mesh shaders for 3D graphics.
The basic idea is having a two step rasterizer: 1 - segmenting curves in to small uniform arc-length segments (because this is the most perceptually simple way of drawing a curve) and iterate along the vertices and allow functions such as (getPoint, getTangent, getNormal, getCurvature, getWeight, getColor,... and other perceptual features of a point of a curve)
2 - actually draw the segments (now here is where the shader gives it's freedom). A normal shader would call the lowlevel drawing commands such as drawLine(lastPoint, getPoint()), with the strokeWeight and Color as they were. But a custom shader could change the alpha depending on the accumulated arcLength (this is an easy way of creating dashes and others) or even change the stroke, weight and color depending on the curvature. Or to call completely different drawing commands.
Am I in a completely different direction of inkscape's developement?
On 4/19/06, Alexandre Prokoudine <alexandre.prokoudine@...400...> wrote:
On 4/19/06, bulia byak wrote:
Later perhaps the same mechanism can be used to implement generic shaders (though SVG 1.1 provides only a fixed set of filters).
That said, how exactly good relations do Inkscape developers have with SVG team to push more features helpful for illustrators? A while ago I tried talking in SVG list about more types of gradient fills and soon I ended up with no replies.
Alexandre
Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmdlnk&kid%120709&bid&3057&d... _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
-- ricard http://www.ricardmarxer.com
On Wed, 19 Apr 2006, Ricard Marxer Pi��n wrote:
The idea of shaders would have to do with being able to have a dash stroke created with a very simple shader language, and in the same way be able to emulate the brush of a pen, penci and others using vector to vector and vector to pixel transformations at the rasterizer level. I know that my idea is not yet defined, but maybe with the help of a mentor, I get things much clearer (I only have one year of experience with vector graphics!!). I only have a first idea of the stroke shader part, I think the fill part could be very much like the mesh shaders for 3D graphics.
I think what you're talking about is similar to the Path Effects that Aaron is working on. The idea there is to take an arbitrary path, then transform it into another path based on some calculation. This could be doing something like a dashed line, or something like a brush stroke, or just applying a slight curve on the edges.
--Ted
On 4/19/06, Ricard Marxer Piñón <ricardmp@...400...> wrote:
I agree that maybe there's no need of two separate renderers, at least at this point. Using the 'Outline mode' might be enough to speed up things.
Oh, and I forgot one more thing: newer renderers tend to use hardware acceleration, which seems to be the main direction of development at this time.
The idea of shaders would have to do with being able to have a dash stroke created with a very simple shader language, and in the same way be able to emulate the brush of a pen, penci and others using vector to vector and vector to pixel transformations at the rasterizer level.
Ah, so this is more similar to the "variable stroke width" idea. We had been discussing this for a long time. Basically, with no SVG support, we will have to "hack" it on top of SVG in back-compatible way.
Now that I think of it, it can be done via the Path Effects mechanism that we're now working on. Aaron: this would be an effect where one parameter holds an array of comma-separated distance-along-path/width pairs. From this data and from the original-d, the effect would create a double-tracked path which would look as a variable-width stroke which follows the original path. The algorithm for creating the stroke from widths can be lifted wholesale from the Calligraphic pen, and the same tool can be used to create such objects using pressure sensitivity. This will give us for free all the advantages of path effects: SVG compatibility, editability of the source path in node tool, etc. Overall I think it's a quite clean way to approach this, and not too difficult to implement (at least after the path effects framework is in place). What do you think?
The basic idea is having a two step rasterizer: 1 - segmenting curves in to small uniform arc-length segments (because this is the most perceptually simple way of drawing a curve) and iterate along the vertices and allow functions such as (getPoint, getTangent, getNormal, getCurvature, getWeight, getColor,... and other perceptual features of a point of a curve)
2 - actually draw the segments (now here is where the shader gives it's freedom). A normal shader would call the lowlevel drawing commands such as drawLine(lastPoint, getPoint()), with the strokeWeight and Color as they were. But a custom shader could change the alpha depending on the accumulated arcLength (this is an easy way of creating dashes and others) or even change the stroke, weight and color depending on the curvature. Or to call completely different drawing commands.
Unfortunately this looks like it's very difficult, if possible at all, to implement in SVG-compatible way. We have an absolute requirement that any Inkscape SVG file must display the same in any compliant SVG renderer, and we're not planning to drop this requirement.
-- bulia byak Inkscape. Draw Freely. http://www.inkscape.org
bulia byak wrote:
Ah, so this is more similar to the "variable stroke width" idea. We had been discussing this for a long time. Basically, with no SVG support, we will have to "hack" it on top of SVG in back-compatible way.
Now that I think of it, it can be done via the Path Effects mechanism that we're now working on. Aaron: this would be an effect where one parameter holds an array of comma-separated distance-along-path/width pairs. From this data and from the original-d, the effect would create a double-tracked path which would look as a variable-width stroke which follows the original path. The algorithm for creating the stroke from widths can be lifted wholesale from the Calligraphic pen, and the same tool can be used to create such objects using pressure sensitivity. This will give us for free all the advantages of path effects: SVG compatibility, editability of the source path in node tool, etc. Overall I think it's a quite clean way to approach this, and not too difficult to implement (at least after the path effects framework is in place). What do you think?
<snip />
Unfortunately this looks like it's very difficult, if possible at all, to implement in SVG-compatible way. We have an absolute requirement that any Inkscape SVG file must display the same in any compliant SVG renderer, and we're not planning to drop this requirement.
I think path effects would be a great SoC project. I think we'll soon see this mechanism open up all sorts of possibilities for advanced abilities built on top of what SVG provides. But using what SVG provides is the key. While the SVG limitation can be, well, limiting, it also gives us a great chance to exercise our creativity.
Aaron Spike
On 4/19/06, Aaron Spike <aaron@...749...> wrote:
I think path effects would be a great SoC project.
Sure. I didn't propose that because you were working on it and I didn't want to pull it from under you :) But if you think that you can share some or all of the work, we can put it up for grabs by SoCers.
-- bulia byak Inkscape. Draw Freely. http://www.inkscape.org
bulia byak wrote:
On 4/19/06, Aaron Spike <aaron@...749...> wrote:
I think path effects would be a great SoC project.
Sure. I didn't propose that because you were working on it and I didn't want to pull it from under you :) But if you think that you can share some or all of the work, we can put it up for grabs by SoCers.
Hehe, I am always ready to share some or all of any type of work. Please let's encourage a SoCer to take on this interesting and remarkable project.
As for me, I think I would actually like to attempt some elementary refactoring as a next project, if I can get proper direction from the resident wizards.
Aaron Spike
On Wed, Apr 19, 2006 at 08:05:13PM +0400, Alexandre Prokoudine wrote:
On 4/19/06, bulia byak wrote:
Later perhaps the same mechanism can be used to implement generic shaders (though SVG 1.1 provides only a fixed set of filters).
That said, how exactly good relations do Inkscape developers have with SVG team to push more features helpful for illustrators? A while ago I tried talking in SVG list about more types of gradient fills and soon I ended up with no replies.
They've accepted our comments in the past, and signs are good that they'll be including us in future discussions, so if you have ideas for things to bring to the SVG group, this list would be a good place to bring them up. If a concensus can be built around these ideas here in Inkscape, then they'd likely have more momentum when proposing them to the SVG group. (Especially so if inkscape also has a working proof of concept...)
Bryce
participants (7)
-
unknown＠example.com -
Aaron Spike -
Alexandre Prokoudine -
Bryce Harrington -
bulia byak -
MenTaLguY -
Ricard Marxer Piñón