On 22 Apr 2010, at 23:29, Krzysztof Kosiński <tweenk.pl@...400...> wrote:
W dniu 16 kwietnia 2010 17:12 użytkownik bulia byak <buliabyak@...400...> napisał:
I think caching, if done properly, will give a huge interactivity gain. Right now, when you move a canvas item such as a handle or node, objects underneath it have to be redrawn (within the touched 16x16 tiles) starting from scratch - tesselating, stroking, filling, etc., even if they didn't change, which is one of the major contributors to the "feeling of slow". If these redraws can be pulled from a cache, it will feel much more responsive I think.
For dragging, the first optimization that comes to my mind is as follows
- We determine whether all the dragged or modified objects are
adjacent in the z-order 2. If they aren't we skip this optimization as it's going to be too complex 3. We render the canvas into 3 layers: below the dragged object(s), above it and a layer with the object(s) itself 4. On every drag we redraw only the portion with the affected object and composite the output from those three layers
I think this might not work when filters come into the picture though.
I know of several cad/cae programs that when your in a graphics intensive shaded view or similar render simpler versions whilst dragging, so having the Option to ignore filters whilst dragging may be of benefit to us. maybe render something that gives a feel of boundaries so you can position, but don't render them properly. (or just use a much cruder filter representation)
The problem with image surface is that it's never going to be really fast - it's just software rendering. And a problem with offscreen GL surface, as you said, is that it may not be available everywhere.
Obviously we need both. :)
One final note: please try to keep both new and old rendering functioning together for as long as possible, with an easy way to switch between them (ideally without restart), so that the new renderer can be quickly checked for correctness and speed. This is a critical point in ensuring a smooth transition! Also, this will be another reason to limit refactoring to the necessary minimum, so as to not disable the old rendering code unless absolutely unavoidable.
I am afraid this might go the way of the failed gtkmm rewrite attempt, and could limit my options. I would need to duplicate the display and libnr directories to do anything meaningful. Isn't it enough to work in a branch?
Regards, Krzysztof
Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel