Defining Pet Features and Essentials
ambassador at fourthworld.com
Wed Feb 12 18:02:26 CET 2014
Ender Nafi wrote:
>> modern limits for object sizes
> Current object sizes go up to about 32' - how big do you need them?
> The problem is the limits of group objects, here.
> 40’ images or graphics are useless most of the time, I know.
> But groups are must-have for scrolling, both on mobile and on desktop.
> Think a video news app for iPhone 5 like Vimeo
> or Twitter app for Mac desktop.
> Let’s assume each thumb is 300px high.
> Then the developer would have been limited to ~100 videos.
> It’s not much.
> I did a quick test and it took 8 fast scrolling flick to get the 100th video in Vimeo for iOS.
> Considering a Twitter-like news reader app; it’s really a tight limit.
Many years ago I submitted a request for this myself:
But since then, I find myself very much on the fence about it, as it's
not quite as simple as just changing the addressing used for rects.
Trevor's earlier post addresses this well:
One of the challenges here is the buffer size: LC provides very smooth
scrolling for groups because it buffers the group's contents. Creating
a buffer of say 64' on a side would take a tremendous amount of memory
in any application.
Most apps handle this as Trevor describes, similar to how his DataGrid
works, with portions of the displayed content paging in and out of
memory as needed on the fly.
Twitter's a really good example there: in my feed it only goes back as
far as about 14 hrs, and won't even attempt to load anything more than
that. And for the content it does show, it makes separate requests for
chunks of about 20 or 30 at a time, updating the scrollbar each time as
Twitter's UI would be well suited for LC's DataGrid.
LiveCode training and consulting: http://www.fourthworld.com
Webzine for LiveCode developers: http://www.LiveCodeJournal.com
Follow me on Twitter: http://twitter.com/FourthWorldSys
More information about the use-livecode