Virtual Scrolling window

[Richard Gaskin]

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