Hello I'm not 100% sure yet whether I'll be able to participate in GSoC 2011, but here are my ideas. They can be used by other potential participants.
1. Selections
A lot of functions in Inkscape operate on the current selection. This includes things like moving objects to another layer, creating a bitmap copy, etc. This leads to a lot of unnecessary code duplication when some other function needs to reuse selection-specific logic in a way that is not tied to the UI. It also precludes any useful implementation of scripting (e.g. one that does not need to modify the user's selection every time a script is run). In order to rectify this, we should create an object that represents an arbitrary collection of SVG elements. It would work like the selection we have now, but would not be tied to any UI elements - it would just represent an ordered set of elements that can be passed to functions.
2. Fix flowtext
Use svg:switch to fix flowtext. Make svg:switch transparent to the SP tree - e.g. a switch should not have its own SP element, the active part of the switch should be transparently included into the SP tree. This can be accomplished by allowing every object to have more than one representation.
3. Make XML private
Discussed before. Was the object of a previous year project, but the main effect of that was mass renaming and moving of code into classes rather than any meaningful improvement in encapsulation. The main thing we need is an ability to create SP nodes. Right now we create XML nodes and rely on SP tree callbacks to construct the SP node for us.
4. Typed XML tree
The XML tree stores strings, which is rather wasteful and leads to a lot of boilerplate in SP object implementations. We have enough knowledge about the document at the XML level to know the type of each attribute and CSS property based on its name. Storing parsed values would save space, particularly for embedded images, at the cost of slightly more expensive saving. GVariant could be used.
5. GTK3 compatibility
This would involve removal of deprecated code, so that Inkscape compiles with both GTK2 and GTK3.
6. 2geom improvements
Move and rewrite code 2geom to the point where it can take over the job of livarot, libavoid, etc. Document the new code and make sure it fits nicely with existing code. The scope of the project could be limited to implementing Boolean operations on paths.
7. Rendering speed improvements
Further work on the Cairo branch in several small sub-projects: a) Instead of re-rendering the same pixels every time a new tile of a filter is rendered, cache them until the rendering is done. The implementation could involve allocating screen-size bitmaps for each layer of a filtered object and filling them with data in small increments. b) Render editing controls to a separate image that is composited on top of the drawing, so that what a path outline is highlighted, there is no need to re-render the object under it. c) Render each layer of the drawing to a separate image; alternatively, render 3 images: everything below current layer, current layer and everything above. This would allow the user to give us some hints.
Regards, Krzysztof
Hey Krzysztof,
I hope we do get you back again. 1, 6, & 7 are most appealing to me personally.
With 1, I do think that looking into the way Adobe products handle selections to add appropriate related features (because to me it sounds like a compatible backend for the functionality) would be beneficial. Basically, just look into what their Selection menu offers. I understand the goal is UI independent, but if it doesn't broaden the scope too much, some UI work on it would really be great.
I think 6 could be most beneficial to the refactoring and getting old code out of the tree. Plus maybe with work on the boolean operations in 2geom, we could finally get some important operations that are currently lacking.
As for 7, as much as I want to see improved rendering performance and for us to do things in a better way, the statement of "further work on the cairo branch" is unappealing. I would really rather see the cairo branch merged back prior to GSoC, and when GSoC starts, starting a new branch. Plus, tracking how much memory "bloat" takes place with caching would be good as well, as we went from satan to saintly with my testing on the Cairo branch and I don't want to see us get too evil again.
Either way, very good list of ideas!
Cheers, Josh
2011/3/27 Krzysztof Kosiński <tweenk.pl@...400...>
Hello I'm not 100% sure yet whether I'll be able to participate in GSoC 2011, but here are my ideas. They can be used by other potential participants.
- Selections
A lot of functions in Inkscape operate on the current selection. This includes things like moving objects to another layer, creating a bitmap copy, etc. This leads to a lot of unnecessary code duplication when some other function needs to reuse selection-specific logic in a way that is not tied to the UI. It also precludes any useful implementation of scripting (e.g. one that does not need to modify the user's selection every time a script is run). In order to rectify this, we should create an object that represents an arbitrary collection of SVG elements. It would work like the selection we have now, but would not be tied to any UI elements - it would just represent an ordered set of elements that can be passed to functions.
- Fix flowtext
Use svg:switch to fix flowtext. Make svg:switch transparent to the SP tree - e.g. a switch should not have its own SP element, the active part of the switch should be transparently included into the SP tree. This can be accomplished by allowing every object to have more than one representation.
- Make XML private
Discussed before. Was the object of a previous year project, but the main effect of that was mass renaming and moving of code into classes rather than any meaningful improvement in encapsulation. The main thing we need is an ability to create SP nodes. Right now we create XML nodes and rely on SP tree callbacks to construct the SP node for us.
- Typed XML tree
The XML tree stores strings, which is rather wasteful and leads to a lot of boilerplate in SP object implementations. We have enough knowledge about the document at the XML level to know the type of each attribute and CSS property based on its name. Storing parsed values would save space, particularly for embedded images, at the cost of slightly more expensive saving. GVariant could be used.
- GTK3 compatibility
This would involve removal of deprecated code, so that Inkscape compiles with both GTK2 and GTK3.
- 2geom improvements
Move and rewrite code 2geom to the point where it can take over the job of livarot, libavoid, etc. Document the new code and make sure it fits nicely with existing code. The scope of the project could be limited to implementing Boolean operations on paths.
- Rendering speed improvements
Further work on the Cairo branch in several small sub-projects: a) Instead of re-rendering the same pixels every time a new tile of a filter is rendered, cache them until the rendering is done. The implementation could involve allocating screen-size bitmaps for each layer of a filtered object and filling them with data in small increments. b) Render editing controls to a separate image that is composited on top of the drawing, so that what a path outline is highlighted, there is no need to re-render the object under it. c) Render each layer of the drawing to a separate image; alternatively, render 3 images: everything below current layer, current layer and everything above. This would allow the user to give us some hints.
Regards, Krzysztof
Enable your software for Intel(R) Active Management Technology to meet the growing manageability and security demands of your customers. Businesses are taking advantage of Intel(R) vPro (TM) technology - will your software be a part of the solution? Download the Intel(R) Manageability Checker today! http://p.sf.net/sfu/intel-dev2devmar _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
On 27-03-11 15:59, Krzysztof Kosiński wrote:
...
- Selections
... 2. Fix flowtext ...
Makes perfect sense.
- Make XML private
Discussed before. Was the object of a previous year project, but the main effect of that was mass renaming and moving of code into classes rather than any meaningful improvement in encapsulation. The main thing we need is an ability to create SP nodes. Right now we create XML nodes and rely on SP tree callbacks to construct the SP node for us.
Would be very, very useful. Especially if we could abstract from SVG enough to make it easier to allow for a different data format in the future (I'm thinking of SVG 2 for example). I imagine this could also help with flowtext-like situations.
- Typed XML tree
The XML tree stores strings, which is rather wasteful and leads to a lot of boilerplate in SP object implementations. We have enough knowledge about the document at the XML level to know the type of each attribute and CSS property based on its name. Storing parsed values would save space, particularly for embedded images, at the cost of slightly more expensive saving. GVariant could be used.
I'm not 100% sure it's still the case, but paths also used to store path data in strings (which may have served a purpose once, but is less important now that we can deal with things like arcs in more places), and there might be similar issues around the codebase. So I think this item could be broader, which also give more flexibility to anyone attempting it.
It is important to be careful while doing this btw, as it can negatively impact Inkscape's ability to round-trip SVG, which is important for many people.
Also, keep in mind that the XML editor also shows serialized values (it's not just when saving a file that you need the serialization). Although I guess it could be cool to let the XML editor deal with typed values...
- GTK3 compatibility
This would involve removal of deprecated code, so that Inkscape compiles with both GTK2 and GTK3.
Sounds like a good idea. Perhaps also a good candidate to put up here: http://wiki.inkscape.org/wiki/index.php/Google_Summer_Of_Code
- 2geom improvements
Move and rewrite code 2geom to the point where it can take over the job of livarot, libavoid, etc. Document the new code and make sure it fits nicely with existing code. The scope of the project could be limited to implementing Boolean operations on paths.
Always a good idea :)
- Rendering speed improvements
Further work on the Cairo branch in several small sub-projects:
I object to the word "branch", as I really, really, really hope it won't be a branch by then. And if it still is, then I think that integrating it with trunk should be more important than pretty much anything else. (Yes, I know I'm stubborn, I also know about the problems with Cairo, but I also know it hurts us to have such an important change out of trunk for such a long time, and I can't help but feel that it should be possible to work around the Cairo issues in some way, even if that means we have to temporarily link statically to an unreleased version of Cairo or something.)
a) Instead of re-rendering the same pixels every time a new tile of a filter is rendered, cache them until the rendering is done. The implementation could involve allocating screen-size bitmaps for each layer of a filtered object and filling them with data in small increments.
I don't completely understand your description, but in general improving caching would be fine. What I don't understand is what you mean by "filling them with data in small increments".
b) Render editing controls to a separate image that is composited on top of the drawing, so that what a path outline is highlighted, there is no need to re-render the object under it.
Ouch, never realized that we do that, that's awful. Should definitely be fixed.
c) Render each layer of the drawing to a separate image; alternatively, render 3 images: everything below current layer, current layer and everything above. This would allow the user to give us some hints.
I could think of a few other ways to reduce the amount of images to store, but in general I think the idea is sound and would be quite useful.
W dniu 28 marca 2011 10:08 użytkownik Jasper van de Gronde <th.v.d.gronde@...528...> napisał:
I object to the word "branch", as I really, really, really hope it won't be a branch by then. And if it still is, then I think that integrating it with trunk should be more important than pretty much anything else.
I agree. Item 7 would make most sense if I managed to merge the Cairo branch before GSoC (I could include it in the proposal as a preparatory task).
I don't completely understand your description, but in general improving caching would be fine. What I don't understand is what you mean by "filling them with data in small increments".
Right now we render each tile by rendering all pixels it depends on, without reusing any data from other tiles. Consider a large radius Gaussian blur applied to a shape: a small tile of the final image depends on a large number of pixels of the shape. We do not reuse any of the rendered pixels of the shape between tiles. This means that every tile of the image needs to render a large area of the shape in order to apply a blur to it. In extreme cases, rendering each tile takes almost as much as rendering the entire canvas.
My idea is to allocate a big image for the shape pixels and keep it around until the entire scene is rendered. Each tile would render a portion of the shape, but would not re-render the pixels of the shape that we already know from the previous tiles. I hope somebody will understand what I mean :)
Regards, Krzysztof
participants (3)
-
Jasper van de Gronde -
Josh Andler -
Krzysztof Kosiński