On 18/02/2007, at 6:45 PM, Tom Benson wrote:
There is a factor, though not significant.
The resulting image from all the graphics operation I perform is
huge, in the tens of MB's.
Accessing the graphics of the canvas ByRef enables me to draw
directly to the original object, instead of duplicating the current
content and then passing the resulting graphics object back to the
container.
It doesn't make much of a difference for smaller routines. but this
routine is physically to big to be contained in a single method,
even too big for two, so I have split it up into 34 different block
drawing sub routines.
As an aside, passing the graphics object ByRef means that two or
more of these sub routines can operate simultaneously (well, not
simultaneously, but co-operatively) on the graphics object at the
same time. Which is necessary for this app, as for why it's
necessary it's a little difficult to explain...
Tom, maybe I'm not getting something, but what about your explanation
makes you think ByRef enables it as opposed to a normal object pointer?
Anything other than a primitive data type like an integer IS passed
"by reference" in Pascal terms (or in C terms, as a pointer).
Say you have something like
sub MangleImage(g as Graphics)
When you call MangleImage with MyCanvas.Graphics, the reference count
in MyCanvas.Graphics is updated and MangleImage receives the same
reference to a Graphics object as exists in the MyCanvas property.
There's no copying of MB's occurring.
In fact, I can't think of a circumstance where passing a Graphics
object ByRef could *ever* make sense - the advantage of using ByRef
means you can create a new object and return it in the parameter but
Graphics objects are always externally supplied by the framework, not
things you should be creating in your code.
regards
Andy
_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>
Search the archives:
<http://support.realsoftware.com/listarchives/lists.html>
