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
On 16/02/2007, at 8:09 AM, Tom Benson wrote:
I have a hugely long graphics rendering routine that I am
splitting up into several sub-routines. Therefore I need to access
the graphics property ByRef,
Why ByRef?
The *intent* of ByRef is so a method called can replace the object
so the caller sees a different object after the call.
Are you trying to achieve some speedup by avoiding object pointer
reference counter updates and if so, does it really help?
Either you haven't quite understood how RB objects work or you have
some cool reason I want to know about ;-)
_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>
Search the archives:
<http://support.realsoftware.com/listarchives/lists.html>
_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>
Search the archives:
<http://support.realsoftware.com/listarchives/lists.html>
