Re: [pyGEF-develop] Hello!
Status: Pre-Alpha
Brought to you by:
hrgerber
From: <pyg...@li...> - 2007-07-19 00:54:54
|
Howdy Chris, On 7/19/07, pyg...@li... < pyg...@li...> wrote: > > Hi Chris > > On 18 Jul 2007, at 11:42 PM, pyg...@li... wrote: > > > 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! Hit testing doesn't really scare me. I come from 3D graphics where we have decent algorithms for real-time N-body object-object collision detection. In comparison, point-object collision detection in 2D is pretty benign. When push comes to shove you can always resort to rasterization for any object you can't reject in some other way. I know, thats why I really liked what you did in floatcanvas with the > hitcanvas. How does that work? I'm not familiar enough with fc. Do you do automate the rasterization for hit testing somehow in a second buffer? 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. Hmm, but that'll give you 24 objects at most. I think sequential testing makes the most sense. You do know their z-order after all, so you can test a stack of things you can't reject any other way by rasterizing them one by one into a hit buffer till you hit one. > 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/ Cool. Thanks for the link. I've heard of those, but hadn't really spent any time looking into what makes the most sense as a spatial index for a canvas (Since it doesn't really seem to be a bottle neck at all right now) > 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. I took a look at how Inkscape is organized. There each component is responsible for generating an inkscape path object that represents it. Basically a GraphicsContext path type thing, but not really tied to any back-end. It's their own internal path object. Then there's a rasterizer component that takes all the paths and is responsible for actually rendering them. Anyway, I think having components generate path objects rather than actually issuing graphics commands makes for a nice separation of objects from GUIs. Inkscape currently has two back-ends, the second one is used for rendering a fast outlines-only mode. 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. I'm not yet convinced that traits.ui is apropriate for more than just rapid prototyping, and a few odds and ends parts of an app's gui. From screenshots I've seen, my impression is that it often generates pretty ugly GUIs when you just let it do its thing. But Traits itself seems like pure winner all the way. Just as soon as they get it untangled from the rest of enthought and installable via PyPi I think it's going to take over the world. --bb |