Re: [pyGEF-develop] About the low-level rendering

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

Hi

On 29 Jun 2007, at 6:33 AM, <pyg...@li...> wrote:

> 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.
>
>
I would also really prefer to avoid this (at this stage at least), as  
doing the extra work NOW could not be worth it in the end.
As I see it, it is going to take quite a while for the pyGEF  
framework to become "complete" and stable.
Hopefully by the time this happen wx.GraphicsContext would have  
pulled up their socks, or .

My idea with the pyGEF framework is to support any developer supplied  
GC. In my current implementation i use the Plotter class that in  
turns make use of the wx.GraphicContext. A developer's specific  
application using pyGEF could replace Plotter with any implementation  
of their choice, as long as it supplies the minimum functionality  
required by the rest of the framework. At this stage it is a bit  
early to define or fix this interface. At some later stage I want to  
be able to support floatcanvas again.

As I see it the requirements of the GC is heavily dependent on the  
application not the framework. So try to create the all singing all  
dancing GC for the framework to satisfy everybody, could in the end  
satisfy None.

So my priorities are as follow:
	1. Stabilize  the pyGEF design, framework and API using traits and  
traits UI.
	2. Implement a complete but basic application to demonstrate all the  
features of pyGEF.
	3. Do work on the GCs  (hopefully some 3D stuff as well).
	4. Add more GCs so the user can simply select one for their  
application.
> 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.
>
>
I will have a look at this.
> 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
>
> ---------------------------------------------------------------------- 
> ---
> This SF.net email is sponsored by DB2 Express
> Download DB2 Express C - the FREE version of DB2 express and take
> control of your XML. No limits. Just data. Click to get it now.
> http://sourceforge.net/powerbar/db2/
> _______________________________________________
> pyGEF-develop mailing list
> pyG...@li...
> https://lists.sourceforge.net/lists/listinfo/pygef-develop
>
--retief