Hello Cal -
What part of NZ are you in? I have a client who wants me down in
Auckland some time around October - maybe we could get Rodney Tamblyn up
from Dunedin and have a mini RevFest. :)
You wrote:
I've been trying to create an APP. Much like a graphics PERT chart.
Something that scrolls forever.
If a PERT chart scrolls forever, what's needed most is a reassessment of
the task it represents. :)
But it seems that the largest stack size, card size or even background.
Group I can create is 32759.
I find that number very strange because of my binary upbringing I should be
able to get 32767 as a width.
Not sure why it's 8 pixels shy, but since 8 is a round number in binary
I'm sure there's some practical reason for it somewhere under the hood,
as Luis suggested.
There's a request to raise this limit at:
http://quality.runrev.com/qacenter/show_bug.cgi?id=1858
Your votes there would be welcome.
But whether the limit is 32,767 or 4,294,967,295, neither is forever.
One difficulty with raising the limit is the amount of memory needed for
buffering. For example, scrolling groups tend to scroll pretty smoothly
in Rev, better than in some other apps I've seen, but this smoothness is
likely a result of imaging the whole group into an offscreen buffer first.
If the limit were raised much beyond 32k, it may require that we also
make a recommendation for a deeper level of memory management, such as
whether to page the buffer in chunks when it renders, and what that
chunk size should be. Shouldn't be impossible, but not likely trivial
either.
So at best the engineers at RunRev could make this a bit easier, but
given the variety of uses I don't see how they could make a
one-size-fits-all solution for us on this without also providing more
lower-level control of memory management.
In your case, Trevor's suggestions make a good starting point. In one
form or another, that's pretty much how this would be approached in most
traditional development systems.
You might also consider putting out different sections of the layout on
multiple cards, going to the next card as needed without the user
needing to be aware that you've changed cards.
If the total memory required for the layout is larger than would be
practical in a single stack, you might consider using separate stack
files, with the "go...in window of..." command to make the transition as
smooth as possible.
But maybe there's a whole different solution for this waiting to be
discovered. Remember that 32,759 is about 37 feet on the printed page.
That's an awful lot of data to present to a user, esp. in something as
visually complex as a PERT chart.
Could it be more useful to the user to break up that representation into
more easily digestible chunks? It may be that the optimal solution
technically is also the optimal solution in terms of usability.
I am confused by the fact that the limits I have run up against are much
less that those quoted by RR officialdom and members of this list.
I don't recall anyone here claiming to have made a stack with an object
size larger than 37 feet, but I'd be interested to learn how if I missed
it. Haven't seen much discussion on card size since you asked about it
in November.
I did find in the old MetaCard docs that the logical limit for stack,
card, and background size is uint4, so this rendering limit appears to
be specific to the interaction between the Mac engine and the Mac OS.
But considering the memory required for such a buffer, I'm not sure how
any system could render a card that big.
So my questions are:
1. Has anyone attempted to use RR to develop a virtual window application.
And if so would you like to
Share your ideas?
Virtual or physical? Trevor has described methods for making it
virtual, but from your description it sounded as though you want to do
the layout on a physical card.
2. Does anyone have real, concrete limitation figures for RR. Not just ones
that depend upon the
Number of stacks in memory?.
I'm not sure where this info is in Rev, but here's the old notes from
the MetaCard Help file:
--------------------------------------------------------------
There are certain limits to how large various structures can be in
MetaCard. Most limits are tied to the machine data types used to store
them. A uint1 is 255 (8 bits), a uint2 is 65,535 bytes (16 bits/64KB),
and a uint4 is 4,294,967,295 bytes (32 bits/4GB). Those structures that
have a maximum size of uint4 share the same 4GB address space and so
each structure can only use space not used by other structures. Note
that all MetaCard structures, including stack size, are limited by
available virtual memory. See also the scriptLimits function.
Stack, card, or bg size uint4
Control (including Image) size uint4
AudioClip or videoClip size uint4
Number of objects in a stack uint4
Number of objects per card or bg uint4
Custom properties per object uint4
Characters in custom property name uint1
Characters in each custom property uint4
Object name length uint2
Characters in a button uint2
All other string properties uint2
Characters in a field or variable uint4
Characters per line in a field uint2
Maximum shadow or border width uint1
Script length uint4
Command or function name length uint2
Nested repeats uint4
Active variables uint4
Message sent to or from external uint2
---------------------------------------------------------------
--
Richard Gaskin
Managing Editor, revJournal
_______________________________________________________
Rev tips, tutorials and more: http://www.revJournal.com
_______________________________________________
use-revolution mailing list
[email protected]
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
