
Hi Krzysz, Two small comments below:
On 25-2-2014 19:17, Krzysztof KosiĆski wrote:
Hello
As promised, here is a description of the project I could do as a student.
The end goal of my MSc project is to write an OpenGL-based 2D scene graph library usable by Inkscape which is capable of displaying most of SVG. Unlike the Cairo OpenGL backend, this library would keep the data on the GPU as long as it's used, and only control points of the curves would be submitted to the GPU, which should give very good performance.
However, this project has several prerequisites. The OpenGL drawing algorithm I'm thinking about (Loop-Blinn) handles only quadratic and cubic Bezier fills, so it would require substantial support from 2Geom to render SVG. http://http.developer.nvidia.com/GPUGems3/gpugems3_ch25.html
For this GSoC, my proposal would be to implement boolean operations and the stroke-to-fill transformation in 2Geom (since I think the latter depends on the former). Some of the required code is already present, for example the code to compute the offset of a single curve, but it's not exposed in an usable form. The project would be both about implementing the missing parts and providing an easy to use API.
Here are the potential work-items:
- Convert Geom::PathVector to a real class.
- Investigate whether it is possible to store curve data in a more
efficient format that does not store every curve endpoint point twice (as a start point and as an end point).
Variant: see if we can store a specialized path type in a vectorizable way (e.g. only curve segments with 4x2 doubles/floats, no virtual functions, etc.) with some specialized implementations using compiler's vector attributes. This to speed up LPE calculations.
- Provide and document an API to the existing intersection code.
- Provide and document an API to the existing curve offset code.
- Implement path uncrossing and monotonization.
- Implement boolean operations, based on the algorithm used in CGAL.
If necessary, add CGAL as a dependency - this is now acceptable, because CGAL in Debian no longer depends on Qt. 7. Implement stroke-to-path.
As a backup option, I'm considering changing my MSc project to implementing a Python scripting console for Inkscape. If I were to pick that instead, the GSoC project could involve a variety of refactoring tasks intended to simplify writing the Python bindings used by the console. In this case, I'm 100% sure that I could do it, whereas in the case of OpenGL I still have some doubts, mainly because I haven't programmed in OpenGL yet.
It'd be great to finish Python bindings for 2Geom, whichever way. I.e., remove the half-finished things we have now, make Python bindings work on popular platforms, and convert a few extensions to py2geom. Most important part of this project would be: *finishing* it. 100% complete 2geom functionality is not needed, but it has to work on all platforms (build instructions, installation instructions, etc). Adding methods is easy afterwards.
cheers, Johan