pygef-develop

[pyGEF-develop] Hello!

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

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!

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/

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

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?

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

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/

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!

I'm very interested to see where this all leads...

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

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

Re: [pyGEF-develop] Hello!

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

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

Re: [pyGEF-develop] Hello!

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

On 19 Jul 2007, at 2:54 AM, pyg...@li... wrote:

> Howdy Chris,
>
> On 7/19/07, pyg...@li... <pygef-=20
> de...@li... > wrote:
> Hi Chris
>
> On 18 Jul 2007, at 11:42 PM, pyg...@li... =20
> 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 =20=

> we have decent algorithms for real-time N-body object-object =20
> collision detection.  In comparison, point-object collision =20
> detection in 2D is pretty benign.  When push comes to shove you can =20=

> always resort to rasterization for any object you can't reject in =20
> 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 =20
> automate the rasterization for hit testing somehow in a second buffer?
>
It is probably better if Chris explains this.

The idea is to draw all object to a second memory canvas, on this =20
hitcanvas each object is drawn with a fill in a unique color. A hit =20
then gets the color at the selected pixel O(1) and then gets the =20
object associated with the color from a hitcolor dictionary O(1). So =20
hit tests take O(1).  Or something along those lines.

> 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 =20
> testing makes the most sense.  You do know their z-order after all, =20=

> so you can test a stack of things you can't reject any other way by =20=

> 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 =20
> would be
> > great, and you might want to check out rtree. I've had it in mind =20=

> 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 =20=

> spent any time looking into what makes the most sense as a spatial =20
> index for a canvas (Since it doesn't really seem to be a bottle =20
> neck at all right now)
>
>
> > Retief wrote:
> >> A developer's specific
> >> application using pyGEF could replace Plotter with any =20
> 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 =20
> is responsible for generating an inkscape path object that =20
> represents it.  Basically a GraphicsContext path type thing, but =20
> not really tied to any back-end.  It's their own internal path =20
> object.  Then there's a rasterizer component that takes all the =20
> paths and is responsible for actually rendering them.  Anyway, I =20
> think having components generate path objects rather than actually =20
> issuing graphics commands makes for a nice separation of objects =20
> from GUIs.  Inkscape currently has two back-ends, the second one is =20=

> 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 =20
> just rapid prototyping, and a few odds and ends parts of an app's =20
> gui.  =46rom screenshots I've seen, my impression is that it often =20
> generates pretty ugly GUIs when you just let it do its thing.  But =20
> Traits itself seems like pure winner all the way.
>  Just as soon as they get it untangled from the rest of enthought =20
> and installable via PyPi I think it's going to take over the world.
>
I agree traits.ui can be pretty ugly if left to do its own thing, but =20=

the idea is not to use it for the entire ui. Traits.ui uses a very =20
comprehensive MVC pattern, that is very useful when using traits. =20
However the views will have to be customized for it to look good. =20
While trying out traits.ui, I wrote a few test apps, where the end =20
result looks like any normal wx app, in only a few lines of code.

In any case, even though the pyGEF uses/can use traits.ui, it does =20
not mean that one would have to use it in the actual application ui.

Traits.ui is also a relatively new lib, Dave started traits way back, =20=

ui only came later. So it will improve.

Have you seen the newest themeing capabilities of traits.ui?
http://www.dmorrill.com/david/other/traits_ui_ss


Here is a little app I wrote to test some more "advanced" (at the =20
time) features of traits.ui. See the interaction between the =20
controls, validation of the property name and value, the updating of =20
the preview and the correct OK/Cancel behavior. Just the ui portion =20
of this app previously used many many hundreds of line of code and =20
still did not work as well.

If you get this app to work, pyGEF should also work.

from enthought.traits.api import HasTraits, Interface, implements, =20
Trait, Float, Int, List, Long, Str, CFloat, Instance
from enthought.traits.api import Delegate, Bool, Any, TraitString
from enthought.traits.ui.api import View, Item, Group, Include, Handler
from enthought.traits.ui.menu import OKButton, CancelButton, Menu, =20
MenuBar, Action

########################################################################=20=

####
########################################################################=20=

####

class IPropertyValue(Interface):
     """
     """

     def eval(self):
         """
         """

     def get_value(self):
         """
         """

     def set_value(self, value):
         """
         """

########################################################################=20=

####
########################################################################=20=

####

class AbstractPropertyValue(HasTraits):
     """
     """

     implements(IPropertyValue)
     value =3D Any

     def eval(self):
         """
         """
         raise NotImplementedError('Method must be overridden in =20
derived class')

     def get_value(self):
         """
         """
         raise NotImplementedError('Method must be overridden in =20
derived class')

     def set_value(self, value):
         """
         """
         raise NotImplementedError('Method must be overridden in =20
derived class')

########################################################################=20=

####
########################################################################=20=

####

class PropertyValue(AbstractPropertyValue):

     value =3D Float

     def eval(self):
         """
         """

         return self.value

     def get_value(self):
         """
         """

         return self.value

     def set_value(self, value):
         """
         """

         self.value =3D value

class PropertyData(HasTraits):
     """
     """

     name =3D Trait('', TraitString(maxlen=3D50, regex=3Dr'^[A-Za-z][A-Za-=
=20
z_0-9]*$'))
     #name =3D Str(maxlen=3D50, regex=3Dr'^[A-Za-z][A-Za-z_0-9]*$')
     value_object =3D Instance(IPropertyValue)
     value =3D Delegate('value_object', modify=3DFalse)
     include_name =3D Bool
     renameable =3D Bool
     preview =3D Str

     def __str__(self):
         """
         """

         propstr =3D''
         if self.include_name:
             propstr +=3D str(self.name) + '=3D'
         propstr +=3D str(self.value_object.eval())
         return propstr

     def _value_changed(self, old, new):
         """
         """

         print('Value changed in PropertyData')
         self.value_object.value =3D new
         self.preview =3D str(self)

     def _anytrait_changed(self, name, old, new):
         """
         """

         print(str(name) + ' thrait changed from ' + str(old) + \
                       ' to ' + str(new) + ' in PropertyData')
         self.preview =3D str(self)

     value_group =3D Group(Item('name', enabled_when=3D'renameable'), \
                         Item('value'))
     option_group =3D Group(Item('renameable'), \
                          Item('include_name'), \
                          orientation=3D'horizontal')
     preview_group =3D Group(Item('preview', style=3D'readonly'), \
                           label=3D'Preview:', \
                           show_labels=3DFalse, show_border=3DTrue)

     readonly_view =3D View(Item('name', style=3D'readonly'), \
                          Item('value', style=3D'readonly'))
     simple_view =3D  View(Item('name', enabled_when=3D'renameable'),
                         Item('value'),
                         buttons=3D[OKButton, CancelButton],
                         kind=3D'modal')
     detailed_view =3D View(Group(value_group, option_group, =20
preview_group), \
                          buttons=3D[OKButton, CancelButton],  \
                          kind=3D'modal')
     view =3D detailed_view

def testPropertyDataModel():
     value_object=3DPropertyValue(value =3D 10)
     p =3D PropertyData(name=3D'value', value_object=3Dvalue_object)
     print '0', p
     p.configure_traits(view=3D'detailed_view')
     print '1 ', p

> --bb
> ----------------------------------------------------------------------=20=

> ---
> 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/=20
> _______________________________________________
> pyGEF-develop mailing list
> pyG...@li...
> https://lists.sourceforge.net/lists/listinfo/pygef-develop

Retief Gerber
Lektor
Lecturer
Departement Elektriese en Elektroniese Ingenieurswese
Department of Electrical and Electronic Engineering

Tel: +27 21 808 4011  I  Faks/Fax: +27 21 808 4981
E-pos/E-mail: hrg...@su...

Universiteit Stellenbosch University
Privaat Sak/Private Bag X1 Matieland 7602
Suid-Afrika/South Africa
www.eng.sun.ac.za


=EF=BF=BC
=EF=BF=BC

Re: [pyGEF-develop] Hello!

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

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


My main problem with Cairo is just that it seems to be overly entangled with
GTK/Linux/GCC.  I don't think it's really a problem inherent in Cairo, just
it seems that's what the current user base is.  It seems to be getting
better slowly though.  AGG has minimal dependencies and compiles pretty
easily. In fact I think Maxim just recommends adding the AGG library files
directly into your project, whatever platform/tool you use.   Maybe from a
Linux user's perspective AGG has the opposite problem of seeming too
Windows-y.  But I think AGG comes with makefiles and such for GCC/Linux
right out of the box.  Anyway, I know Cairo *can* be compiled and used on
Windows, it's just it seems more like at the stage of "Hey look some guy
managed to compile it on Windows too!" as opposed to intentionally and
pro-actively supporting non-Linux, non-GTK usages.

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.


Yeh.  Probably the most interesting thing about AGG is that it is so
pervasively templatized, allowing you to do things like create a dedicated
pipeline for rendering directly to some odd image format just by changing
one parameter and implementing a few low-level rasterization routines.  In
theory anyway  :-).   Anyway AGG is really more a construction kit for
building vertex processing pipelines.  Cairo, I think, is a concrete
implementation of one particular pipeline.

I wonder if it would be possible to use the Xara engine some how (GPL)....


I think the current plan is BSD-like license, but I guess that could change.

--bb

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

Re: [pyGEF-develop] Hello!

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

On 19 Jul 2007, at 9:52 PM, pyg...@li... wrote:

> 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 =20
>>> 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?
>

Something similar to Photoshop, or CADs. My main focus is EDA tools =20
(schematic capture, physical IC design).
For IC the layers represent the actual metal layers.

> 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 =20
> 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=20
> +Foreground
> works OK.
>

I must still get round to trying this on the GC

>  =46rom 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.
>

Probably for some tool tips or something, the new office type popup =20
boxes.

>>> It works with bounding boxes, and can quickly respond to the =20
>>> 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?
>
Jip, but i have been having problems with our proxy. I have a rather =20
complicated setup to connect to the internet from home.
So I will update the code as soon as I can get it to upload again.

> However, it is still order N to search all the BBs, so if you =20
> 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 =20
> would be
> more important for some apps than others to have accurate hit testing.
>
I have also been thinking of something along these lines.
>> 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 =20
> what I'd
> do with a DC, but maybe that would be even slower than a path =20
> inclusion
> test -- if GraphicsContext was well written!
>

Must run some tests

>> This would make interchangeability very difficult or
>> would limit the functionality.
>
> Exactly why I think it's maybe not worth trying. Matplotlib has =20
> 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 =20
> 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 really need to look at Agg now

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

Why?

>> 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 =20
> make
> a DC renderer for pyGEF instead -- you'd have to add some of the =20
> 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
>
>
> --=20
> 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...
>
> ----------------------------------------------------------------------=20=

> ---
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2005.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> pyGEF-develop mailing list
> pyG...@li...
> https://lists.sourceforge.net/lists/listinfo/pygef-develop

Retief Gerber
Lektor
Lecturer
Departement Elektriese en Elektroniese Ingenieurswese
Department of Electrical and Electronic Engineering

Tel: +27 21 808 4011  I  Faks/Fax: +27 21 808 4981
E-pos/E-mail: hrg...@su...

Universiteit Stellenbosch University
Privaat Sak/Private Bag X1 Matieland 7602
Suid-Afrika/South Africa
www.eng.sun.ac.za


=EF=BF=BC
=EF=BF=BC