wow Stuart, thanks for all the great points; i'll just comment a bit and
later i'll add them to our tracker for the path to 0.3.
Stuart Axon wrote:
I think the CORNER, CENTER transformation stuff should still be manageable, we
just need to push/pop objects which handle this, not individual matrices.
true; the difference is just translating and applying the transform
(CENTER), as opposed to applying the transform only (CORNER).
most of this was made harder because of our hacky solution to get the
path bounds (= dimensions and center). I think that's probably one of
the bottlenecks, now that i think of it: to determine the path bounds,
we're creating a new cairo context, drawing the object, measuring it and
then deleting everything. This is total overkill, and something that
should be made a lot more straightforward when we try doing it via 2geom
(more on this below).
Do we still have to reverse the coordinates at the end ? - I wonder if we
could use cairo.scale (or similar) to setup the coordinates we need (maybe we
can use this to flip them).
do we do this coordinate reversal? I can't recall where, to be honest...
...but maybe OT, this is an issue to be dealt with when DrawBot is to be
implemented, since its coordinate system has the origin at the
bottom-left corner. Not sure how easy it will be.
Definitely storing the intermediate matrices preferably in some native format
(lib2geom?) makes the a lot of sense too.
yes, lib2geom has all we need for matrices. Does everything cairo.Matrix
does from what i saw.
WRT refactoring -
I think it can definitely be made simpler.
External api:
A simple external api.
I'd imagine we'd be able to do:
from shoebot import bot, cairo_renderer
shoebot.run(botname, renderer= cairo_renderer)
cairo_frame = shoebot.next_frame()
great point, hadn't thought of this.
something this reminds me is how Processing handles the backend choice:
you specify it in size(), as in
size(1024, 768, OPENGL)
once we have more backends, this might be a way to go too. But your
solution is great when not reading an external script and calling bot
commands from python.
- Probably we should move a lot of the colour transformation methods out of
data and into something like colorsystems.py
totally, as a matter of fact we should look into our file structure:
- gtkui contains both the windowed mode code (when you specify -w) as
well as the IDE. These should definitely be separated.
- the bot and canvas stuff should get out of the __init__.py file and be
moved to something like a shoebot.core module.
- libs should be importable through a module, e.g. 'from shoebot.libs
import sbopencv' or something. Not sure if this is allowed already.
- maybe breaking apart data.py would be in order -- separating
primitives, paths, transforms and colors.
Strings vs references:
I think there are a few places we could use references instead of
if 'somestring'
pass
elif 'someotherstring'
pass
yes! We ought to make a list of where this is happening.
Namespace stuff:
copyattrs seems to show up quite high in the profiling, I wonder if we could do
this in a different way avoiding isinstance
(I wonder if we could also avoid setattr and getattr too)
good to know; it was something copied directly from Nodebox. Wondering
if there's faster methods to do it. Anyway, it's a function that's
called a *lot* of times, so it's bound to be abundant when looking at
debug output.
This sort of thing can be avoided:
if namespace['draw']: ## from memory
We can check if it exists once in the bot at the beginning and add an empty
stub if it doesn't.
good point
Window resizing stuff:
We should be able to resize the window (probably everything inside could just
scale like nodebox(?))
yes, definitely; this would imply having a 'view' instead of the window
replicating the Cairo context, so that scaling wouldn't change the final
output. That would also allow for zooming, panning, etc.
We need to sort out size()
I don't know what nodebox does if you call it in the middle of a script, but I
guess we would just reset the canvas to the new size... being able to do this
might avoid some of the weirdness around here.
yeah -- it does have that issue with calling size() using variables
instead of absolute values, but that's something we can warn against.
but you're right, at the very least it should issue a warning and fail
silently when called more than once.
:r
-- Sorry if this is a bit of a braindump, it's still in my head from playing
with the code last night :)
... + hopefully I will get round to looking at some of these myself.
----- Original Message ----
From: francesco fantoni <[email protected]>
To: [email protected]
Sent: Tuesday, May 12, 2009 1:50:57 PM
Subject: Re: [shoebot-devel] why Shoebot can be slow, and a possible way out
i'm inclined to think that the bottleneck is on how we handle the
transforms -- there's a lot of stuff being calculated and re-calculated
I thought the same. Each graphical object comes with its copy of the
transformations' chain up to the moment of its creation, and at
rendering time we're forced to go through a long chain of
transformations over and over for each object.
It would be faster to store a resulting matrix as state-attribute of the
grobs, calculating it only once and updating it whenever a
transformation command is parsed, but I'm afraid that is possibile only
for CORNER mode transformations I think, as the CENTER mode depends on
each object's coordinates.
I suppose you could calculate the resulting matrix for the CORNER mode
transformations and then "add" the CENTER mode ones on a per-object
basis, but the push-pop loops could really make it impossible to manage
and I suppose the order of application of each transformation could
matter as well, though I'm not sure...
Just for the records- the numpy variant is here:
http://freehg.org/u/hva/shoebot-affine/
on the bright side: after working some more on the 2geom bindings,
they're really close to usable. Some more testing, and maybe we can
start using 2geom in shoebot.
refactored transforms.
I tried to clean and optimize the code, it seems a bit faster now, but
still slower than nodebox.
waiting for a complete rewrite (with lib2geom?)
I've found an affine transformations library using numpy and released
under BSD license, maybe i will try it.
francesco
------------------------------------------------------------------------
_______________________________________________
Shoebot-devel mailing list
[email protected]
http://lists.tinkerhouse.net/listinfo.cgi/shoebot-devel-tinkerhouse.net
_______________________________________________
Shoebot-devel mailing list
[email protected]
http://lists.tinkerhouse.net/listinfo.cgi/shoebot-devel-tinkerhouse.net
_______________________________________________
Shoebot-devel mailing list
[email protected]
http://lists.tinkerhouse.net/listinfo.cgi/shoebot-devel-tinkerhouse.net
