LiveCode Forums.

I read some LC tutorials and two LC books in the last weeks.

In this tutorial/books the authors often use buttons for showing and controlling images.
The image is then a kind of property of the button.

Since there is an image control of its own on the tools palette I wonder why they use buttons as a container for images?

What is the best way or best practise for working with images for background images, (animated) characters or sprites and other kind of graphics in LiveCode?

BTW: Images can be imported via "File/Import as control" and via the image control on the tools palette.
I there an important difference between these two methods?
Which one would you recommend?

Thanks for your help!

Hallo Francesco,

when using an images as an ICON of a button, we can have as many "instances" of that images (in a button)
as we like, but the image is physically only ONCE in the stack! Capisce?

Referenced or imported?
For the user there is no difference. With referenced images we need to supply them in our runtime,
imported images are part of the current stack and thus the filesize gets bigger.


Best

Klaus

Hi.

How do you use a button as a "container" for an image? It is not a property of a button, like an icon. Obviously something I simply did not know about.

Images imported from afar are different from the ones you pull from the tools palette. I have never used the paint tools in LC at all, though I use the graphic tools all the time. But I do pull images when I want, say, a button to have a special "icon" not available from the usual library. But this is a separate control from that button, and the two have no particular relationship with each other.

Much of what you ask is a matter of style. Imported images can be anything at all, collected from wherever or made by you in any way. The ones in the tools palette are rather limited, though you can draw them yourself right inside LC.

Craig

Hi Craig,

dunbarx wrote: ↑

Tue Jan 19, 2021 3:17 pm

How do you use a button as a "container" for an image? It is not a property of a button, like an icon.

don't worry, we are only talking about that namely ICON property of a button here!


Best

Klaus

An image object is good for showing the image once. If you only need it once, that's all you need.

But if you want an image to be rendered in many places, having it displayed as a button's icon will be much more memory efficient, and simpler for your development workflow if you need to change it later.

Richard.

having it displayed as a button's icon will be much more memory efficient

I assume you are speaking of a referenced image, not one resident in a stack file.

But I am still confused. Does the image become in any way at all a property of that button? Or does it simply overlie it to a certain extent to form a pair of controls that travel together? I assume the latter, and can relax.

Craig

dunbarx wrote: ↑

Tue Jan 19, 2021 4:29 pm

I assume you are speaking of a referenced image, not one resident in a stack file.

I'm not sure I understand how it would be more efficient either way.

Case 1 - you have an image brought into a stack. Whether you use 50 buttons with that image as the icon, or 50 image objects using that image, I don't see how the image changes anything (except that icons are usually simpler affairs than say, a 200 x 200 picture). For the sake of argument, I will assume the image is the same size regardless of placement (button or image object).

How does one become more memory efficient than the other? Does the button footprint take up less memory than the image object?

Case 2 - you have an image referenced - I can see this being more memory efficient, as the image is not loaded until called for, but again the question becomes how does being the icon of a button make it more efficient than just being displayed as (one or more) image objects?

What am I missing?

-
BUTTON / GRAPHIC / ORIGINAL IMAGE

how does being the icon of a button make it more efficient than just being displayed as (one or more) image objects?

Displayed as one image object won't make any difference at all.

But (take a look at my picture in the previous post), if the image is displayed 3 times, a button with the image set as its icon, or
a graphic object with the image set as its back ground pattern means that an image weighing in at,
say, 1 MB, only has to be imported once (= 1MB) rather than 3 times (= 3MB), meaning that your stack will be significantly smaller.

dunbarx wrote: ↑

Tue Jan 19, 2021 4:29 pm

Richard.

having it displayed as a button's icon will be much more memory efficient

I assume you are speaking of a referenced image, not one resident in a stack file.

Neither. I was referring to the OP's question about button icons.

Regardless where the source image is stored, it needs to be decompressed, rendered into its own buffer, and then composited into the card rendering.

When using multiple image objects, each object maintains its own buffer.

But if you have only one image object, and it's displayed multiple times in buttons via the icon property, each button uses a pointer to the original image object buffer.

So the savings (other details notwithstanding), is roughly the size of the decompressed image minus the four bytes for the pointer, times the number of buttons displaying the image as an icon.

Not only does this save an appreciable amount of memory, but also saves CPU time with fewer bits to shuffle around.

dunbarx wrote: ↑

Tue Jan 19, 2021 4:29 pm

But I am still confused. Does the image become in any way at all a property of that button? Or does it simply overlie it to a certain extent to form a pair of controls that travel together? I assume the latter, and can relax.

We're just talking about using the imported image's ID as a button icon. That's the same as any button icon regardless of how it got into the stack.

AH, setting the icon property to an image ID.

OK. I got mixed up with the "container" thing.

Craig

FourthWorld wrote: ↑

Tue Jan 19, 2021 6:24 pm

When using multiple image objects, each object maintains its own buffer.

But if you have only one image object, and it's displayed multiple times in buttons via the icon property, each button uses a pointer to the original image object buffer.

jacque wrote: ↑

Tue Jan 19, 2021 6:32 pm

We're just talking about using the imported image's ID as a button icon. That's the same as any button icon regardless of how it got into the stack.

AAAAhhhhhhhhhhhh <lightbulb>

I've taken to using SVG widgets instead of buttons as they take up less memory than a bitmap and more importantly are eminently scalable. Obviously this can limit what i use as a 'button' and i have to add little bit of extra code... Not sure if that's the 'right' thing to do...

Whatever is the most fun is the right thing to do.

Craig