Re: [pyGEF-develop] Hello!

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

pyg...@li... wrote:
>> 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,

yes. I decided to simply not support that feature, but it has come up.

> 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.

hmmm -- maybe if you have alpha blending, you could do something with 
that. This would take a bit of thought.

The other downside of the FC approach is that it needs to render every 
hit-able object twice, so hit-testing is blindingly fast, but overall 
rendering is slowed down. As it's usually not useful to have 1000s of 
hitable objects shown at once, it's not a big deal.

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

Some memory issues -- I only have one or two now. Of course, maybe you 
don't need to have all the layers hitable? What are layers for?

Early in FC development, I started with an n-layer (each with an 
off-screen bitmap) approach, but that required that the the layers be 
transparent, which for the old DC meant a mask, and I found rendering 
was really slow -- so I dropped it.

if GraphicsContext can render transparent bitmaps fast, then I guess it 
would be nice, but in practice, I find you're usually only really 
changing one layer at time, so the FC approach of Background+Foreground 
works OK.

 From a users perspective, it's nice to have more layers, so I've 
thought of having layers, but not drawing them to separate bitmaps.

> I'm aware of this, but currently the actual drawing is the biggest  
> bottleneck with the GC.

premature optimization is the root of all evil...

> As far  
> as I can remember fc also redrew the entire visible canvas at a time.  

Yes.

> I want to be able to only redraw the dirty region of a dirty layer.  

That wouldn't be hard to add to FC -- I've just never bothered.

> 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. :)).

How often is it used? I had a use case in mind, but honestly, I'm not 
sure I've used it for anything real after all.

>> 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.

yup -- will that replace your BoundingBox.py code?

However, it is still order N to search all the BBs, so if you really do 
have 1000s of objects, then an order log(N) search would be better -- 
but wait until there's a problem.

>  not  
> everything is rectangular. This is something that has bothered me,  
> but I found that many "vector" drawing apps only use the bb.

And those that do drive me crazy!

> Thus  
> boundingbox is not the best way, but it is much faster than using  
> path inclusion tests.

Well, the compromise is to test BBs first, then only do path inclusion 
for those that hit -- and I suppose it could be an option -- it would be 
more important for some apps than others to have accurate hit testing.

 > Again here is where your hitcanvas shines. :)

That's why I did it that way. Another option other than path inclusion 
is to create a very small bitmap, centered around the mouse position, 
then draw the object to it and see if any pixels change. That's what I'd 
do with a DC, but maybe that would be even slower than a path inclusion 
test -- if GraphicsContext was well written!

> This would make interchangeability very difficult or  
> would limit the functionality.

Exactly why I think it's maybe not worth trying. Matplotlib has done it, 
but it's a lot of extra work -- and they are moving toward the *Agg 
back-ends -- i.e. rendering with Agg, then transferring the bitmap to 
whatever GUI toolkit is used. That way all the drawing can be done with 
Agg. They are also starting to use Cairo - but they have licensing 
issues it unfortunately -- it would save them a lot of pain.

> 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.

Agreed.

> In this kind of design, it is the  
> GraphicPrimitives that define the l.c.d., not entirely the canvas/ 
> context.

well, sort of. In a simple case, if you're using a wxDC -- you can't 
have transparency -- at least not easily! So the renderer is limiting 
what you can do -  but maybe having the same framework for different 
uses and capabilities still makes sense.

Indeed, with wx -- maybe we can mix GraphicsContext and DCs -- for 
simple drawing, use DCs for performance, and use GraphicsContext for 
added features when required.

> Then one also gets to the question: What should be part of  
> the framework, and what should be part of the app.

yup -- that's hard -- I've struggled a lot with that with FloatCanvas.

> As an example: It only took me about a day to move my demo app from  
> using fc to using GC.

What that's pretty quick!

> 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.

hmm. doing affine transforms on coordinate based objects (polygons, 
lines) would be easy -- but Circles and whatnot may be harder...

> The main reason for wanting to use fc as backend, is that it is much  
> faster than the GC.

That's probably the DC vs. GraphicsContext issue, so maybe you can make 
a DC renderer for pyGEF instead -- you'd have to add some of the affine 
transform stuff though.

? 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.

Maybe, but the point is the same -- much of FloatCanvas is no longer 
necessary.

> 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.

See my other note, but yes I've had my eye on traits for FC too -- and 
it looks like it's starting to  get some wider use outside Enthought.

-Chris


-- 
Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R            (206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115       (206) 526-6317   main reception

Chr...@no...