Re: [pyGEF-develop] Hello!

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

Hi Chris

On 18 Jul 2007, at 11:42 PM, pyg...@li... wrote:

> Hi Retief, Bill, and ???,
>

> I figured it was time to keep an eye on what you've been up to, it
> certainly looks like some good stuff, so I've joined the list.
>
> I scanned through the mailing list a bit, and have a few thoughts  
> to share:
>
> On hit testing code:
>
> If you want to capture the mouse-leave and mouse-enter events, then  
> hit
> testing has to be fast it has to be done for every motion event --  
> which
> is a lot!
>

I know, thats why I really liked what you did in floatcanvas with the  
hitcanvas.
Overlapping objects is just a problem, but I suppose one can use some  
form of color mixing to create a new color when objects overlap and  
store lists of objects associated with a hit color.

Having 10 layers, each with a hit canvas could pose a problem.

> bb wrote:
>> building a hierarchy on the
>> document bounding boxes so you avoid having to do lots of  
>> transforms into
>> individual object coordinates is probably the better way to go.  
>> That'll
>> give O(lg N) performance in hit testing, whereas improving  
>> individual hit
>> tests will still give you something that's O(N).
>
> Are you talking about some sort of spatial index? If so, that would be
> great, and you might want to check out rtree. I've had it in mind for
> FloatCanvas for a while:
>
> http://zcologia.com/news/433/rtree-0-1-0/
>

I'm aware of this, but currently the actual drawing is the biggest  
bottleneck with the GC. So after stabilizing the higher level editing  
framework stuff, I will move over to optimizing the drawing. As far  
as I can remember fc also redrew the entire visible canvas at a time.  
I want to be able to only redraw the dirty region of a dirty layer.  
After this I think hitting will be the next biggest bottleneck,  
especially if enter and exit events must also be handled (At this  
stage I have quietly ignored this feature. :)).

> It works with bounding boxes, and can quickly respond to the question:
> what BBs is this point in? and what BBs intersect this BB?
>

Bill wrote a small geom library in pyrex, that I use for my hittest,  
so it should be really fast.

> Another note:
>
> It sounds like you're defining hitting as a hit within the Bounding  
> Box
> of the object, which is really not that good -- there are times  
> when you
>   really want the hit to be a hit on the object itself -- or have I
> missed something?
>

Yes, currently the hit is tested against the boundingbox around an  
object, as it is a simple < or > that x,y,w,h type test. BUT not  
everything is rectangular. This is something that has bothered me,  
but I found that many "vector" drawing apps only use the bb. Thus  
boundingbox is not the best way, but it is much faster than using  
path inclusion tests. Again here is where your hitcanvas shines. :)

> Retief wrote:
>> 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.
>
> I've always been pretty skeptical of "backend-independent" systems.
> You're kind of stuck with the lowest common denominator. As it is,
> GraphicsContext is a backend independent wrapper, as is Cairo  
> (though at
> least Cairo does it's own in-memory bitmap rendering).
>

Maybe I can clarify this a bit. You are correct that l.c.d. always  
rules when trying to create an interchangeable back-end. The problem  
is that the API's of the different possible back-ends differ quite  
substantially. This would make interchangeability very difficult or  
would limit the functionality. pyGEF as an MVC framework must provide  
high-level framework and structure to a graphically oriented  
application.

> Actually, Cairo has a lot going for it -- it's powerful, flexible,  
> under
> active development, and is being used by Major projects (GTK and
> Mozilla). It also gives you other output options: PDF, Postscript,  
> Printer?
>
> I understand Agg is faster - I wish Cairo used Agg as it's in-memory
> renderer, but as it started with that part, it probably never will,  
> and
> at this point, I don't know that Agg really is any better than Cairo.
> And performance improvements will come.
>
> I wonder if it would be possible to use the Xara engine some how  
> (GPL)....
>
> http://www.xaraxtreme.org/
>
I do need to look at these other back-ends, but again, to get the  
higher level stuff stable and well structured is more important now.  
The current framework does not really depend that much on the actual  
drawing back-end. The most important dependency is that the canvas/ 
context must support AffineTransforms or provide a means of  
"simulating" them. The GraphicPrimitives (rect, cir, DrawObject(fc),  
etc.) depend on the drawing back-end, so each drawing backend will  
provide its own set of graphic primitives. These primitives will  
probably not be usable on other back-ends. Then the Views will depend  
on the GraphicPrimitives, i.e. Views will be defined for a specific  
back-end. One can then define multiple Views on multiple back-ends  
for the same "Document". In this kind of design, it is the  
GraphicPrimitives that define the l.c.d., not entirely the canvas/ 
context. Then one also gets to the question: What should be part of  
the framework, and what should be part of the app.

As an example: It only took me about a day to move my demo app from  
using fc to using GC. Obviously I first had to figure out how GC  
worked. In the meantime though a lot of the APIs have changed quite a  
bit and AffineTransforms are heavily used (something that fc does not  
support) so moving back to fc might be a little bit more difficult,  
but not impossible.

> Oh, and about using FloatCanvas as a back-end -- it seems it  
> overlaps so
> much with pyGEF, that there really wouldn't be much point. Indeed, I'm
> here to see if it's time to drop FloatCanvas and move the pyGEF!
>

The main reason for wanting to use fc as backend, is that it is much  
faster than the GC. I would also not say that pyGEF overlaps that  
much with fc, I think it is the new GC that provides a lot of the  
same functionality as fc. Myself and I think many other people,  
needed an editing framework, that would

> I'm very interested to see where this all leads...
>
Chris, have you looked at the traits and traits.ui libraries by  
enthought. I am also trying to fit pyGEF into their design structure,  
because I think they did some really good work.

--retief