image question (for everyone)
hello Jacqueline, In response to my problem of building a standalone, you asked: Does it have a lot of images? Well, actually it does. But I had the same problem building an app with no images. I changed the drive to which I build apps and both built just fine. Don't know why. Anyway, my new question is this: Since you asked about a lot of images, does LC have some kind of limit on how many images can be used in a stack? I have over 20 images in the stack that are primarily being used as custom designed buttons. Thanks, Larry P.S. Of course I'm not just asking Jacque about this, but the entire forum. ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: image question (for everyone)
On 4/10/14, 11:41 AM, la...@significantplanet.org wrote: I changed the drive to which I build apps and both built just fine. Don't know why. Me either, that's pretty odd. I wonder if the standalone builder is looking for resources in the wrong place. Now that you've narrowed it down, it would be worth a bug report to save others some trouble. Anyway, my new question is this: Since you asked about a lot of images, does LC have some kind of limit on how many images can be used in a stack? I have over 20 images in the stack that are primarily being used as custom designed buttons. There's no limit outside of what your computer can handle, and 20 button icons is tiny. The issue isn't the number of images but rather the size of all of them combined (after expanding any jpgs.) I was bitten by this in a project where I was storing a whole lot of large images in the stack (moving images to external files wasn't possible in this case.) LiveCode's image caching scheme, which I wasn't used to yet at the time, means it loads all of those into RAM at once, and in my case that came out to a couple of gigs of memory. I was crashing every few minutes and decided that the new version was too buggy for use. No one else had any trouble but I couldn't run it at all. I reverted back to the previous version, which didn't have image caching, but I didn't put the two together at the time. I went through support channels and it turns out it was because I was storing all these huge images in a hidden group. The actual visibility of the images doesn't matter, if the group is placed on a card they will load into RAM in preparation for being shown. I was exceeding the amount of RAM available by a large margin and LiveCode just shut down unexpectedly after a couple of card changes. In my case, the solution was to unplace the group from any cards; an unplaced group can still serve as a storage repository but won't be loaded into the image cache because it isn't potentially viewable. Immediately after that, LiveCode because quite stable. So it was all my own doing. I get so used to the reliability of LiveCode that I forget sometimes that I need to be responsible myself for the consequences of my actions. -- Jacqueline Landman Gay | jac...@hyperactivesw.com HyperActive Software | http://www.hyperactivesw.com ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: image question (for everyone)
I KNEW there had to be a good use for unplaced groups! Thanks. Do you think it still works that way? Phil On 4/10/14, 10:56 AM, J. Landman Gay wrote: In my case, the solution was to unplace the group from any cards; an unplaced group can still serve as a storage repository but won't be loaded into the image cache because it isn't potentially viewable. -- Phil Davis ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: image question (for everyone)
I really appreciate you posting this. It's pretty eye opening for someone less under-the-hood savvy like me who has been told for years that LiveCode loads everything into memory at startup. I would never guess that load into memory could have two different definitions. Regards, Scott Rossi Creative Director Tactile Media, UX/UI Design On 4/10/14 10:56 AM, J. Landman Gay jac...@hyperactivesw.com wrote: I was storing all these huge images in a hidden group. The actual visibility of the images doesn't matter, if the group is placed on a card they will load into RAM in preparation for being shown. I was exceeding the amount of RAM available by a large margin and LiveCode just shut down unexpectedly after a couple of card changes. In my case, the solution was to unplace the group from any cards; an unplaced group can still serve as a storage repository but won't be loaded into the image cache because it isn't potentially viewable. Immediately after that, LiveCode because quite stable. ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: image question (for everyone)
On 4/10/14, 1:14 PM, Phil Davis wrote: I KNEW there had to be a good use for unplaced groups! Thanks. Do you think it still works that way? It does, I'm still working with the project. In retrospect I could have used a substack but there are so many other substacks that I didn't want to add another. For no good reason I guess. I learned the trick in MetaCard, which uses an unplaced group for all the HC icons it imports. -- Jacqueline Landman Gay | jac...@hyperactivesw.com HyperActive Software | http://www.hyperactivesw.com ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: image question (for everyone)
Yeah, I had to talk to Mark Waddingham about it at one of the conferences before I understood what I was doing. He asked me how many images and what size each one was in pixels, whipped out his calculator, and showed me a calculation that overran the length of the display. Neither of us tried to figure out where the commas would go to see how many hundreds of thousands of bytes were actually in there. Everything really is loaded into RAM as before when the stack opens so that part hasn't changed (but I think any jpgs remain compressed until they are displayed.) But then any images potentially viewable on a card are loaded a second time into the image cache, which is flushed regularly as new images replace older ones. But in my case the group was a background group that was placed on every card, and it had all the images for the whole stack in it (long story) so LC was trying to load a huge inventory twice -- once when opening the stack, and again to the cache on every card change. I suppose I was asking for a couple of gigs of RAM by that point and LC just expired in resignation without so much as a so sorry. On 4/10/14, 2:07 PM, Scott Rossi wrote: I really appreciate you posting this. It's pretty eye opening for someone less under-the-hood savvy like me who has been told for years that LiveCode loads everything into memory at startup. I would never guess that load into memory could have two different definitions. Regards, Scott Rossi Creative Director Tactile Media, UX/UI Design On 4/10/14 10:56 AM, J. Landman Gay jac...@hyperactivesw.com wrote: I was storing all these huge images in a hidden group. The actual visibility of the images doesn't matter, if the group is placed on a card they will load into RAM in preparation for being shown. I was exceeding the amount of RAM available by a large margin and LiveCode just shut down unexpectedly after a couple of card changes. In my case, the solution was to unplace the group from any cards; an unplaced group can still serve as a storage repository but won't be loaded into the image cache because it isn't potentially viewable. Immediately after that, LiveCode because quite stable. ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode -- Jacqueline Landman Gay | jac...@hyperactivesw.com HyperActive Software | http://www.hyperactivesw.com ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
