For some background on what is going on:
I am making a Drawing game using EditableImages, and currently to display your drawing the server sends the buffer of the EditableImage from EditableImage:ReadPixelsBuffer() to all clients. Once the clients have this buffer, they then create an EditableImage and do EditableImage:WritePixelsBuffer() to display the user’s drawing on an ImageLabel. At this point, the Image no longer needs to be editable, it is just for display.
What I want to achieve is the following:
Since the EditableImage is being written to an ImageLabel and doesn’t need to be edited anymore, I want to figure out how to compress the image or have it take up less memory some way if this is even possible. This compression would ideally take place on the client side after they have written the EditableImage to the ImageLabel.
The issue is that during testing, displaying a highly complex drawing takes up the same amount of memory as a simple drawing. Currently with drawing sizes of 512x512 an EditableImage takes up: (512 x 512 x 4(for RGBA)) = ~1MB of memory. This is how much memory is taken up on the client side for everybody who has a displayed drawing. (e.g. If there are 20 people on the server with displayed drawings, then every client would spend ~20MB of memory displaying everyone’s drawings). I believe if I am able to use some sort of compression on the data this can be drastically reduced and even allow me to use 1024x1024 EditableImages.
The only alternative I can think of is streaming the EditableImages, but this doesn’t account for the wasted memory. I would appreciate any help, ideas, or even confirmation that this isn’t possible. Thanks! (This is my first post on devforum, how did I do)?
Yeah this is a really good question, and I’ve also run into this issue.
From what I understand, once you write to an EditableImage using WritePixelsBuffer(), it still holds the full RGBA buffer in memory, even if you’re only using it for display. So yeah just displaying the image doesn’t make it use less memory.
Right now there isn’t any built-in way to compress that memory or convert the EditableImage into something lighter like a static texture on the client. The buffer stays in memory regardless of whether you’re editing it or not.
The only actual workaround I can think of would be:
Uploading the image as a compressed asset (PNG/JPEG) somewhere
Then setting ImageLabel.Image to a URL or rbxassetid://... if you host or import it
That obviously comes with a bunch of issues like needing a backend or asset uploads, which might not be realistic for a lot of games.
Otherwise yeah, every client is going to spend about 1MB per 512x512 EditableImage, even if it’s static. I don’t think there’s any current method to offload that memory after writing.
Would be really useful if Roblox gave more control over discarding or compressing the pixel buffer after use.
You explained it well though, and your math checks out this is definitely a real limitation.
For the workaround you suggested, I found in Assets | Documentation - Roblox Creator Hub the following: "https or http points to the exact location of something on the internet. It only works on Roblox-approved domains and raises an error if you use it elsewhere." So if I made a backend server which compresses the image and provides a URL, would I need to find a way to get it on the Roblox-approved domains list?
Also, are you also suggesting that it could be possible to upload the image to roblox as an asset? It appears that according to Usage guide for assets | Documentation - Roblox Creator Hub I would have to upload a Decal in .png, .jpeg, .bmp, or .tga format.
If this is as it seems I think I’ll bite the bullet and see what kind of memory savings I can get from streaming the images. Hopefully when replication is supported for Content values they’ll be sufficiently compressed.
Yeah, if you’re planning to stream the images through a backend, you’ll either need to host them on a Roblox-approved domain or upload them as actual assets. You’re totally right though Roblox blocks external image links unless they’re whitelisted.
And yeah, I was referring to uploading them as decals. You’d write the buffer to an image on your backend, compress it, and either use that image in a Decal or rbxassetid://... once it’s uploaded.
Not ideal for dynamic stuff but could work if you cache them right. Hopefully Roblox adds a better way to discard EditableImage memory…
I requested to be added to the feature requester group, if accepted I’ll probably post a feature request for an API like EditableImage:Compress() and EditableImage:Decompress(), allowing the EditableImage to be static and take up less memory.
