[pyGEF-develop] About the low-level rendering

[<pyg...@li...>]

You were saying you noticed some low level differences in positioning
/ rendering in wx.GraphicsContext on different platforms.  I'm finding
that too.  Also font scaling seems odd, and it seems difficult to
consistently render a bitmap at pixel-for-pixel on the screen (for
rendering grab handles regardless of view scale).  Scaling of stroke
widths seems also to be very odd.  There are big jumps in the width
when you pass a certain scale.

I asked about GraphicsContext on the wxWidgets dev list and it seems
like the response was that no one was really working on it right now,
and there aren't really any improvements in the works, though they
generally agreed with my comments on things that need to be done.  So
it may be going in the right direction, but it's not going there any
time soon.

This is making me think maybe it would be better to implement our own
GraphicsContext-like class on top of a platform-independent renderer
like Agg or Cairo.  That way all rendering will be guaranteed platform
independent, and additionally it would give us better access to the
innards.  I.e. if a feature is missing or a bug is found it could be
fixed in the local rendering lib rather than requiring getting the fix
into wxWidgets itself and waiting for it to percolate through to
wxPython.

- In Cairo's favor it's pretty full featured, and will probably
eventually be available as an official implementation of
wx.GraphicsContext on all platforms (there's already a wxCairoContext
in the "generic" directory of wxWidgets' source, just not compiled for
Windows usually).   On the down side, the only way I've ever seen
Cairo compiled on Windows is using GNU tools, so I suspect it doesn't
have a very portable build system.  There's a pyCairo project I found
but it appears to be Unix only.

- Agg is not as feature-ful in many respects, and has a very unusual
API.  But it is quite fast and generates nice-looking output.  The
most promising thing for making a GraphicsContext subclass out of it
seemed to me to be the Graphin project, which provides a GC-like API
in C implemented using AGG that could easily be wrapped by a Python
class.  I used Agg on my last project and was happy with everything
but the peculiar API.  But with this Graphin wrapper it should be less
painful.  Graphin will probably require a little work to get compiling
on platforms besides Windows, though.

That said, really I'd like to avoid the above if at all possible.
It's doable and would have some benefits, but would end up being a lot
work.  Really, mostly what I'm seeing as odd with GraphicsContext seem
to be things related to the use of GraphicsContext's transform.  So it
might be easier just to redo things to handle the view transform on my
own and let GraphicsContext think it's drawing at 1-to-1 all the time.

Really in the end, if you want to give a vector drawing program
fancier features, you need to do your own stroking as no standard API
can handle things like variable width strokes automatically.   In that
regard the work that lib2geom (http://lib2geom.sourceforge.net/) folks
are doing seems interesting.

But most of this stuff is really only of interest to a vector drawing
app.  I suspect it's less of an issue for a Simulink type of thing
where you can probably get by with the simple stroke/fill options the
API gives you.

--bb