Nitro wrote:
>> > Bitmaps are about 100 times slower
> Robin replied that bitmap drawing will get faster in future versions
> (unless the bitmaps are constantly changing). Do you want to rely on that
> or not?
I just posted a note about that -- we'll see.
I think sometime soon we should summarize some of the core decisions,
like what versions we're planning on supporting, etc, and post that to
the wxPython list to solicit feedback.
> The conclusion is a bit indeterminate. I am all for coding things, then
> benchmarking, then optimizing.
yup -- that's the way to go.
> Ok, sounds like we should abandon the hit-test bitmap approach in this
> case. Maybe use bounding boxes and then for the fine things something like
> the "pixel changes" or the Path.Contains approach.
Yes, inherently more flexible.
> we should just test it and see how it goes.
Yup.
> Say the user has a database of a flowerbed with positions for all flowers.
> Then he could hook fc somehow so that the flowers in the db correspond
> with the flowers seen in fc. This means creating/deleting the nodes in the
> fc scenegraph (document).
Right, but this could just as easily be accomplished by
creating/deleting/altering entire DrawObjects. There are some slight
performance gains possible with the more MVC approach (more shared
objects), but I'm not yet convinced that we get anything else. ON the
other hand, if we can wrap it up in an easy-to-use interface, then maybe
we don't lose anything either.
> Not sure if you count this as "Float canvas
> object level" or "each flower is a view and together they form the entire
> document".
Well, the entire document is a view of the entire database, while each
node is a view of each individual flower -- this makes my head hurt!
Maybe this comes down to this:
How do want to handle the changing of an individual flower?
1) The flower object gets changed -- it notifies the flowerbed model
that a change has occurred. The flowerbed model sends out a message that
something has changed, and the FloatCanvas Scenegraph can respond to that.
2) The flower object gets changed -- it sends out a message that it has
changed, and both the flowerbed model and the Scenegraph can respond to
that change.
If was summarize these questions, maybe we can send them to some key
people, like perhaps the folks that wrote or contributed to the MVC/MVP
pages on the wxPython list.
>>> And yes, the IFlowerData is an interface (hence the I- prefix)
>> OK -- I'll look up zope interfaces, though it feels a bit JAVA-ish to me!
>
> Yes, it doesn't feel to pythonic. But the user needs some
> code/documentation when he wants to extend things. Interfaces tend to be
> ok for that.
If you think you want to do formal interfaces, code up an example, and
lets see.
By the way, I do like the idea of Enthought Traits -- we should
definitely consider using that -- I think we can bundle the package so
it won't be an external dependency. At least until you can do
"easy_install traits" reliably on all platforms.
> Ok, we can do it this way: The user plugs his custom views in at the
> nodes. The nodes hold the transform (their main job), the data, the look
> and the renderable. This is something like the DrawObject then.
sounding good -- why not call it a draw object? Or something more
descriptive than node.
> No need to
> subclass the entire node then. Just exchange the attributes on the fly.
> For example if you'd want to change the renderable to render rectangles
> instead of circles, you could change it on the fly. Inhertiance is bad
> here since you can't change the way an object (object=data) is rendered on
> the fly (like changing between a renderable which renders a flower in
> different ways) easily.
Yup -- I see this as the key advantage.
> If each map is created as an individual
> object then you don't know that you can share the cache, too and end up
> with 100 bitmaps instead of 1. Now if you want to add a line or two to the
> map then change 1 object is easier than 100.
> Doing it by inheritance seems to have a problem: Say you want to draw 100
> red circles and 100 green circles. How do you do this without creating two
> different PopulationCircle classes?
It could be done, but:
> I think inheritance doesn't really scale well to compositing. It destroys
> the idea that things are orthogonal to each other.
I see you point. This and the ability to swap functionality is cleaner.
We do need to keep in mind the need for easy-to use factory functions so
that the simple things are easy, and the complex things are possible.
Maybe it's time to do some code up of demos -- you may be able to fit
this into the existing FloatCanvas Framework, by adding a wrapper that
mimics the DrawObject API. Everything but the transforms, anyway.
> I am not sure I understand the problem here and how it relates to having
> more than one renderer for an object. I'd write your example like this
>
> class PointsData(list):
> # instead of subclassing from list, one could also subclass from
> object and then add this:
right -- I wouldn't subclass from list --
1) I think of a pointsdata object as Using a list, rather than Being a
list
2) It should be a numpy.ndarray anyway!
> # def __init__(self, points):
> # self.points = points
>
> # can eventually omit this
> class LinesData(PointsData):
> pass
> # Do you want to add a ConvertToSpline() method here?
This is the question, I think they way you're setting it up, it doesn't
belong there, as whether it's a Spline or Line isn't a property of the
LinesData object at all.
> class LineRenderer(IRenderable):
> def Render(self, renderer, data):
> renderer.DrawLines(data)
>
> class SplineRenderer(IRenderable):
> def Render(self, renderer, data):
> renderer.DrawSpline(data)
>
> myLine = LinesData( [ (1,2), (3,4) ] )
> myLineRenderer = LineRenderer()
> myLineRenderer.Render( renderer, myLine )
yup. Except this needs to be wrapped up in a class(your node?), so there
is one object for the user to deal with. And we need the factory functions:
def Spline(points, ...)
spline = Node()
spline.Data = LinesData(points)
spline.Renderer = SplineRenderer
spline.Style = LineStyle(...)
return spline
Now you have a node object that you can do things like:
MyLine = Spline(....)
and get a Spline.
MyLine.Renderer = LineRenderer
And it's now a Line.
I'm liking this.
> I agree. We need a complete use case example. I'll write up one with the
> usage as I intend it. Then we'll continue discussion on that. After we
> have finished the use case discussion I'd like to stop theorizing and then
> actually start coding and do refinements as we go along. What do you think?
sounds good.
> I think this should be configurable. Hence the notion of a RenderSurface
> (we can also call it RenderTarget). If you tell the layer to draw to a
> bitmap, it's drawn to a bitmap, if you tell the layer to directly draw to
> the window, then it will be drawn there. Layers should not be coupled to
> any buffers directly.
I like that. Not sure if whether a layer gets rendered to its own bitmap
or directly to the main one is a property of the layer or manged by the
main rendering code...
> The other options is to make some kind of importer hook where the svg file
> is loaded and convert it to fc native renderables.
I think this is the way to go.
> Using svg as a general format to load/save a whole fc is impossible I
> think.
I agree -- that's not how I see FloatCanvas being used -- it's about
representing data, not representing a drawing -- SVG is for representing
a drawing.
> Ahh, I see your point. Then this transformation has to be done manually
> anyways. GC uses wxDouble everywhere, it probably maps to the C++ double
> type (python float == C++ double). But I don't know whether the underlying
> platform supports the real double range/precision or is cast to float.
good question, though I'd guess it's double where it matters.
> In any case, it's better than an int :-)
yup!
> I can only test on XP. No other platforms around here. If we really need
> to I can probably setup a virtual machine with linux, but not unless it's
> absolutely necessary.
Yes -- I saw your post on the wxPython list!
> Any float canvas users here who use linux and would
> like to help testing?
Let's put a call out for testing when we get something to test. We
should be testing on the three major platforms early on though. I can
probably support Linux and OS-X, but if there end up being frequent
issues, it might be worth your setting up a Linux VM or partition.
-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
[EMAIL PROTECTED]
_______________________________________________
FloatCanvas mailing list
[email protected]
http://mail.mithis.com/cgi-bin/mailman/listinfo/floatcanvas
