Sent: Tue, January 12, 2010 8:17:09 AM
Subject: Re: [shoebot-devel] Gedit integration on Windows status...
Post by Stuart AxonHehe, already been told off for top-posting (altho will do it here, as yahoo
mail is a pain in the arse).... I really want to try shoebot with newer cairo,
as it might be faster... (+ also, we need to work with current versions of
libraries).
Not to mention that we ought to test with Python 2.6, since that's the
default on Ubuntu 9.10 and Snow Leopard. I'm not expecting big issues
(in fact, i've been working with it on py2.6 without problems, only
realised that now.)
I imagine on linux the newest cairo is also used, I need to find out if theres a problem with the way I've installed it on Windows, or if it's the Windows version.
If you have a Windows box, try the recipe I've posted and see if you get the same errors.
Post by Stuart AxonPerformance is my big issue at the moment, I realise it's fixable in the
- now inkscape 0.47 is out there must be a new lib2geom,
Yeah, the big problem with 2geom is that there's no actual 'release'.
There was a thread at inkscape-devel regarding this problem, since
Inkscape bundles its own 2geom library. This is a major PITA, since i'm
really not into maintaining and checking for new versions of a local copy.
Also, I've found that Cairo-based operations (e.g. determining path
bounds) are quite faster than 2geom. Of course 2geom provides
higher-level operations (e.g. adding/subtracting paths), so in the end
that should be our goal. But there's still a way to go, i'm afraid...
Maybe packaging 2geom and its python bindings would be a good help
towards this end.
I guess since I now have msvc installed it might be possible - the current build from
http://wiki.inkscape.org/wiki/index.php/Lib2geom_py2geom#Microsoft_Windows
is from October.
Post by Stuart Axon- newer versions of cairo have fixes that could help
I haven't followed cairo-dev for a long time. Was there any relevant new
feature that we should be aware of?
Looking throught the Changelogs, there seems to be a lot of stuff about correctness, and they start looking out for performance regressions too.
Here are some of the things I found interesting, since 1.4.x:
Cairo 1.5.8
Performance improvement
-----------------------
Improve performance of clipping by using an optimized code path
internally, (with the ADD operator instead of IN).
1.5.10
- Looks like SVG backend is a little faster
"Avoid unnecessary rasterization when copying a "similar" surface to another svg surface"
1.6.0
- Robustness fixes
cairo_path_extents -- this sounds like it could be useful to us,
for calculating the centre of objects.
.. some optimisations mentioned in intervening versions, but not specifically to win32
1.9.2
Profiling tools:
cairo-trace generates a human-readable, replayable, compact(-ish!)
representation of the sequences of drawing commands made by an
application.
Under the util/cairo-script directory is a library to replay traces.
1.9.4
cairo_meta_surface_create()
cairo_meta_surface_ink_extents()
Finally exporting the internal meta-surface so that applications
have a method to record and replay a sequence of drawing commands.
cairo_in_clip()
Determines whether a given point is inside the current clip.
??? Should this be called cairo_in_paint() instead? in-clip is the test
that is performed, but in-paint would be similar to in-fill and in-stroke.
Experimental backends, including opengl:
OpenGL - An advanced OpenGL compositor. The aim is to write a integrate
directed rendering using OpenGL at a high-level into Cairo. In
contrast to the previous attempt using Glitz which tried to
implement the RENDER protocol on top of OpenGL, using the
high-level interface should permit greater flexibility and
more offloading onto the GPU.
The initial work on the backend was performed by Eric Anholt.
Post by Stuart Axon- work on accelerated cairo seems to have started again
Awesome -- IIRC they were busy with an OpenGL branch, which would free
us from having to create a new backend!
The opengl stuff has great promise, in fact in an earlier Changelog
they mention an aim of an 80% performance improvement in the tesselator.
Also, if we want to mix cairo and opengl, I imagine having an opengl backend could reduce a lot of the overhead in doing this (at the moment you have to render cairo to memory and copy it to texture).
Post by Stuart AxonI don't know if it's relevant but I saw on a cairo mailing list somewhere that
it's quicker to path everything out and then draw it, not sure if that could
help us.
I think that's what Shoebot does now -- pass all the drawables to a
Cairo context, and then draw all of them at once.
_______________________________________________
Shoebot-devel mailing list
http://lists.tinkerhouse.net/listinfo.cgi/shoebot-devel-tinkerhouse.net