Just a couple notes -- more later:
> Bitmaps are about 100 times slower
well Darn. I was hoping they'd be faster!, at least with transparency.
> My results were obtained on Vista x64, so keep this in mind.
hmm. you'd think that would support native drawing for all of this, and
thus be as fast as it gets -- anyway, it's the newest platform, so we'd
better support it well.
> I haven't benchmarked this in-depth, but it seems either this varies
> heavily by platform
We'll see.
>or only matters for lots of objects.
I thought it mattered for objects with large paths -- This came from
Chris Mellon's experience with an SVG renderer. You might look for that
in the wxPython-users archives.
> This is true. Might be hard to select an object which is completely hidden
> behind another one.
I have had that feature request.
> Well, if you want to separate data (model) from view, then you need one
> object dealing with the data and one with viewing it. The data does not
> have to know how to draw itself. Besides that there might be multiple ways
> to draw the same data. So in essence this is data-view decoupling.
Yes, though from a user perspective, they have their data, and the
FloatCanvas object is the view (see my population example), so this
comes down to: Is there a benefit to MVC style at the FloatCanvas object
level?
> 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!
> Well, maybe ICircleData will not have a center property :-). The scene
> node takes already care of transforming it,
So then the location of the circle becomes a property of the Renderer?
Or Node? I'm getting confused here... That makes sense for this example,
but sometimes the location is part of the data, but the diameter not --
I think it may be too implementation specific to specify this way.
> 00 circles with
> radius=10 and have only 1 circle data object (although you have 100 nodes).
If each Circle is the same class, the what is the advantage of having
one Circle, and 100 nodes, rather than 100 circles? Maybe some memory
advantage, but since I don't think we can determine a priori which data
is shared, and which individual, I don't know that we can do it. On the
other hand, this structure allows users to design their own objects that
share what they want to share. Can't that be done with subclassing and
class attributes, though:
class PopulationCircle(FC.DrawObjects.Circle):
color = 'red'
def __init__(self, diameter, xy):
self.diameter = diameter
Now you can create a bunch of PopulationCircle objects, each with a
different diameter, but they will all be red, and they all share
everything else the same.
>>> You could also have multiple FlowerRenderers for the same FlowerData
>>> (they might render it differently).
>> That is cool -- though you could do this with subclassing too -- which
>> is easier to use??
>
> Subclassing what from what?
Subclassing from a FlowerObject -- overriding the Render method.
That may not allow you to drop a different renderer into an existing
instance though (well, you can do almost anything with python, but not
as cleanly). An example I've though of for this is the Line and Spline
objects - they really are the same except for the renderer. In the
current version, spline is subclassed from Line, with the _Draw method
overridden:
class Spline(Line):
def __init__(self, *args, **kwargs):
Line.__init__(self, *args, **kwargs)
def _Draw(self, dc , WorldToPixel, ScaleWorldToPixel, HTdc=None):
Points = WorldToPixel(self.Points)
dc.SetPen(self.Pen)
dc.DrawSpline(Points)
if HTdc and self.HitAble:
HTdc.SetPen(self.HitPen)
HTdc.DrawSpline(Points)
So now we have two classes that share everything except how they are
rendered. This works fine, until you ask: How do you turn a Line into a
Spline? This is a common operation in drawing programs.
Of course, I could have built them as a single class, with a "IsSpline"
attribute, and the rendering would switch on that -- but that doesn't
anticipate users adding their own way to render a Line-like object, and
being able to switch between them.
> Maybe you
> are right and we should collapse renderable and look into one object ala
> RenderSet and change the RenderSet in this case. Or the IRenderable.Render
> function is not only passed the renderer, but also the look which can then
> be modified by the Renderable. Or the IRenderable can set/return a custom
> look instead of the default one. This needs further thought though.
OK -- we need a straw-man example -- I'm still confused about what is
what here!
>> some
>> objects have a lot more complications -- see ScaledTextBox for example
>> -- where would all that other code go?
Maybe a straw man would help here. And ScaledTextBox is a good example,
as it's as complicated as it gets in the current floatcanvas (though
ScaledBitmap is getting there!
> OK. I'd like to make the "foreground" thing part of a general layer
> concept though.
Agreed -- what I'm not sure about is if each later gets it's own buffer
-- that would depend on how fast it is to blit a transparent bitmap --
it used to be dog slow. Also memory use, of course.
> See the benchmark code. DC DrawBitmap seems to be blazingly fast on my
> machine, although there's still the "is alpha 0-255 or just on/off"
> question.
I haven't tested since alpha bitmaps were introduced -- they do exist,
but they may follow a different code path. though the old "mask" code
path was what was slow.
>> Which reminds me -- have you looked at the SVG model at all? Does it
>> follow any of these ideas?
>
> I haven't looked at it yet, all I know is that it's some kind of xml
> document.
I haven't looked closely either, but it does have a path-based and
object-based drawing model -- it may be informative.
> The intermediary transforms would probably be cached. Things like zooming
> can be handled by the DC.SetUserScale and GC.SetTransform methods.
not DC.SetUserScale -- DCs require integers, so that all goes to heck
when your world coordinates may vary between 0-1. That's why I didn't
use it. I'm not sure about GCs -- do they use float or double?
> Or no location at all! And that's when you need a separate view model.
So the location is part of the Document(Scene?) model, rather than the
FlowerModel?
>> yes, I do want that -- FC now has a ViewPort and a Scale. I'm not sure
>> you need anything else for 2-d.
>
> Probably not. Maybe some weird projection :-)
actually, that is an issue -- the viewport is rectangular in Pixel
coords, it has to be, and I think it has to be in Projected coords, but
it may not be in World coords. Then we'd need to go to an arbitrary
polygon (quadrilateral, at least?). As a straight line in Projected
isn't a straight line in World -- now I know why GIS systems generally
work in projected coordinates. But I think we can probably get away with
that for now -- if need be, it could be accommodated by a
projection-dependent Bounding Box check -- define the four corners, and
ask the question -- is this object inside that box? more complex math,
but the same question.
> Ok. Please tell me when you see ugly parts in my code (not counting the
> Benchmark).
Will do. I tend to write a bit in my own style, which isn't quite the
wxPython style, so correct me too!
>> Then there's version support: I'm inclined to say wxPython2.8+ and
>> Python 2.5+ (though wxPython supports 2.4), but we might want to poll
>> users about that -- I'm often surprised to find people constrained to
>> old versions.
>
> Ok, I will developing and testing on wxPython 2.8.7 msw-unicode and python
> 2.5.
Do you have any other platforms? I can test on OS-X and WinXP. I'm not
using Linux much lately, though I'd like to get back to that.
-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
