Definitely faster than all the roblox drawing systems I’ve seen. Has lightning speed and good optimization being able to run on super low end devices.
2 Likes
I’ve tested it myself, and it’s incredibly fast with no noticeable FPS drops. Great job! I’m really excited for this game to be released to the public!
1 Like
chat they made rhotoshop (rotoshop?) before gta 6
1 Like
Why the gta 6?! Everyone knows its not gonna release that soon bruh (idk mabye 28837392 years later?)
1 Like
Definitely, let me know how it’ll perform once you complete it 
A few discord users in Discord called the results of the tests flawed, and said I using older versions of the modules, so here’s a completely new one with the latest version of each.
Performance Comparisons between latest version of OSGL, CanvasDraw, and Ro-Photoshop:
OSGL (1024x1024 Canvas - 512 Circle Radius Drawing) Video:
OSGL V1.6B:
CanvasDraw (1024x1024 Canvas - 512 Circle Radius Drawing) Video:
CanvasDraw Version 4.14.0:
Ro-Photoshop:
Wanna test it yourself?
OSGL Test Place
CanvasDraw Test Place
Ro-Photoshop Test Place
In both CanvasDraw, and OSGL with Blending Mode: Difference FPS Dropped to 1, so I didn’t bother to add them into the public test place. In case, anyone is still not sure about this, feel free to write your own Code for each in Canvas 1024x1024, Circle Radius: 512. Both APIs are easy to use, and wouldn’t take more than 3 minutes each.
Blending Mode: Normal - Canvas 1024x1024 - Circle Radius: 512 Performance Results:
CanvasDraw Average FPS: 3
OSGL Average FPS: 2
Ro-Photoshop No FPS drop felt, whatever FPS you have, it stays that.
Been tested in over 6 devices; in any module other than Ro-Photoshop FPS dropped to below 10, while Ro-Photoshop has been the only one with NO FPS Drop!
In case you write your own script for each to test them yourself, make sure the test is in Roblox Client and not Roblox Studio for the test results not to be biased.
I want to clear something up about OSGL’s and CanvasDraw’s performance numbers. I totally get that lower - end devices can struggle, but when I tested this myself, I noticed something interesting:
- For OSGL, your example place gave me the same results you mentioned - around 100 FPS at rest, and ~3 while rendering.
- For OSGL, when I wrote the code from scratch, (same setup: 512x512 circles on 1024x1024, drawing on mouse hold), my FPS sat at a solid 240 when idle, only dropping to ~100 during rendering.
A similar occurrence happened while testing with CanvasDraw.
OSGL Testing Code
--!optimize 2
--[[
OSGL Render Benchmark (v1.6b) - Circle Stress Test
==================================================
Tests single-threaded rendering performance by drawing
512x512 circles at mouse position while pressed.
Test Parameters:
• Resolution: 1024x1024
• Draw Call: 512x512 circle (filled)
• Condition: While mouse button is down
• Thread: Single (main thread only)
==================================================
]]
-- Wait a delay of 5s, in-case any Roblox services interfere.
task.wait(5)
local ReplicatedStorage = game:GetService("ReplicatedStorage")
local Players = game:GetService("Players")
local RunService = game:GetService("RunService")
local UserInputService = game:GetService("UserInputService")
local Public = ReplicatedStorage.Public
local OSGL = require(Public.OSGL)
local Window = OSGL.Window
local Color = OSGL.color
local RED = Color.RED
local Player = Players.LocalPlayer
assert(Player)
local PlayerGui = Player.PlayerGui
local Screen = PlayerGui:WaitForChild("Screen")
local Canvas = Screen.Canvas
local WIDTH, HEIGHT = 1024, 1024
local program = Window.from(Canvas, WIDTH, HEIGHT):Unwrap()
while task.wait() do
local inWindow, X, Y = program:GetRelativeMousePosition(Canvas)
if inWindow and UserInputService:IsMouseButtonPressed(Enum.UserInputType.MouseButton1) then
program:Circle(X, Y, 512, RED)
program:Render()
end
end
OSGL Circle Performance Stress Test.rbxl (80.2 KB)
Honest question - what’s going on in your implementation that’s tanking performance at rest ? Mine idles at cap until you start drawing.
Results
– Idle: [Roblox Cap]
– Drawing: ~100FPS
CanvasDraw Testing code
--!optimize 2
--[[
CanvasDraw Render Benchmark (4.14.0) - Circle Stress Test
==================================================
Tests single-threaded rendering performance by drawing
512x512 circles at mouse position while pressed.
Test Parameters:
• Resolution: 1024x1024
• Draw Call: 512x512 circle (filled)
• Condition: While mouse button is down
• Thread: Single (main thread only)
==================================================
]]
-- Wait a delay of 5s, in-case any Roblox services interfere.
task.wait(5)
local ReplicatedStorage = game:GetService("ReplicatedStorage")
local Players = game:GetService("Players")
local RunService = game:GetService("RunService")
local UserInputService = game:GetService("UserInputService")
local Public = ReplicatedStorage.Public
local CD = require(Public.CanvasDraw)
local Player = Players.LocalPlayer
assert(Player)
local PlayerGui = Player.PlayerGui
local Screen = PlayerGui:WaitForChild("Screen")
local Canvas = Screen.Canvas
local WIDTH, HEIGHT = 1024, 1024
local program = CD.new(Canvas, Vector2.new(WIDTH, HEIGHT))
program.AutoRender = true
local RED = Color3.fromRGB(255, 0, 0)
while task.wait() do
local inWindow = program:MouseIsOnTop()
if inWindow and UserInputService:IsMouseButtonPressed(Enum.UserInputType.MouseButton1) then
local XY = program:GetMousePoint()
program:DrawCircle(XY, 512, RED)
end
end
Once again, CanvasDraw yields similar numbers to OSGL, yet vastly different to yours.
Results
– Idle: 120FPS
– Drawing: 30 - 50FPS
CanvasDraw Circle Performance Stress Test.rbxl (131.5 KB)
Both RBXMs have been provided. Please could you provide yours? I’m genuinely curious (and I’m sure @Ethanthegrand14 would also be) why 100FPS is seemingly lost? I apologise if any of this came across as rude, but I want to understand how you got this result. It is clear that Ro-Photoshop is faster than both CanvasDraw and OSGL - and I’m not debating that. By default both libraries are single-threaded, whilst you support numerous threads, so it’s clear that you will yield higher performance. Perhaps run it on 1 thread so we can compare performance that way? If mine, as well as those “6+ devices” all yielded 3FPS or so while rendering a circle, it seems that possibly there may be something wrong with your code. Yet again, my aim is not to publicly degrade you, nor your library, I simply want to understand what’s happening behind the scenes here.
These were tested in a public game - My personal account does not have access to the EditableImage API and so I used a friends place. Feel free to publish these and try it in the real Roblox client. The difference between Studio & the Roblox client shouldn’t make that large of a performance difference, however.
3 Likes
Hey @saaawdust, Indeed it’s not rude if you’re wondering about anything, and questioning why things are the way they are. As a matter of fact, I’d encourage to continue to do so. I am very open to do that, and if anyone wants to challenge this module, I couldn’t be more open. Regarding your concerns related to the huge FPS difference, it seems to be because of your device being much faster than ours. This is your rbxl files, saved and published to Roblox, and me testing them:
Video (streamable expires in 2 days):
or Download from discord directly:
https://cdn.discordapp.com/attachments/871000868277866516/1360607517142679712/2025-04-12_16-23-29.mp4?ex=67fbbbfe&is=67fa6a7e&hm=83399e9a8a70be53de39b21bcb42a8bf7474d0e1674190011c0f6272ae73b92c&
The only difference between our test places, was that I was using RenderStepped, and you while task.wait().
1 Like
By default both libraries are single-threaded, whilst you support numerous threads, so it’s clear that you will yield higher performance. Perhaps run it on 1 thread so we can compare performance that way?
A bit late, I was trying to find a decent way to reduce ‘Cores’, the first idea was to hardcode 1 Actor, however, that wouldn’t seem too convincing so I ended up setting affinity of Roblox Studio to only 1 CPU Core to show you that it can actually run in a Nokia with no lags (~1-2 Threads), but you have to take into consideration that the whole Roblox Engine was slowed down along with it yet it had no FPS Drop.
Was Tested in Roblox Studio, I wouldn’t mind testing it in Roblox Client aswell if you would like me to do that aswell.
Here’s the video of it running in 1 CPU Core Roblox Studio:
If you have any question or doubts, let me know. Black Magic never fails to impress 
Hi. Since you’re now using a single thread, we can clearly see the FPS dropping to 90-100. Anyway, here’s a test place for OSGL (unrelated to the old one.)
OSGL Circle Performance Stress Test.rbxl (80.3 KB)
I would love if u can test this one :). Results from multiple devices:
- 240 idle, 180 drawing
- 240 idle, 152 drawing
- 240 idle, 210 drawing
- 240 idle, 230-240 drawing (this final device is only limited by the Roblox cap.)
Hey, In single-thread my FPS didn’t drop to 90-100 while drawing. My idle FPS was 90-100 and FPS stayed the same while drawing.
Regarding your new test place, It’s much faster, however, there’s still 40-70 FPS drop for me while drawing in it. In Ro-Photoshop even with single-threaded, there’s no FPS drop while drawing.
I’d like to also see other blending modes with this, other than just basic color with alpha 1. Since basic color only can be pre-cached very easily. Smoothening the edges of it, and implementing blending modes, brush strokes would be the next challenge. Ro-Photoshop also has dealt with all of these at lightning-speed.
At first level, I’d like to just see Difference Blending Mode.
This comment serves as a warning for all developers who wish to use this module.
I apologize in advance if this ever comes out as harsh or rude, but someone has to say it.
Firstly, note how RoPhotoshop is worded here.
EditableImages had only come out of beta late 2024, and as of writing, it is early 2025. “thousands of hours” here is objectively unrealistic. The first quote is completely unprofessional and condescending, not to mention the improper grammar used throughout the post (and this is coming from a person whose english is their 3rd language).
I will also point out things said in the second part of the quote that accomplish nothing and are not remotely related to EditableImages and Parallel Luau.
Roblox is closed-source software, and you cannot internally change LuauVM. Luau is open-source now, and I applaud the creators if they did go as far as analyzing the source code, but that would not help since you cannot change how LuauVM internally operates on Roblox. I also fail to understand how they were able to “take full advantage” of the GPU since Luau does not yet provide an interface to communicate with the GPU. The GPU is handled internally within the backend of the Roblox engine, so please enlighten me if the previous statement is wrong. And as far as I know, there is no way to uniquely identify hardware on the roblox client (if that is what is meant in the quote… as I said, phrasing is improper), nor can you actually fully utilize the CPU with Luau alone.
Also note that this type of terminology is also shared in the “Featured Game”: “It’s handled by a very complicated system with external server, a custom made database system and tons of more stuff …”
Secondly, I would like to point out the method that is used to gauge and compare the performance of RoPhotoshop with competitors. This video was shared in the original post:
It is painfully obvious that the time at which the ImageLabel updates does not match the time at which the roblox engine renders the frame. The method shown in the video measures the roblox engine FPS, not the ImageLabel FPS. To correct this, consider using RunService.RenderStepped instead, which runs at the same “clock” as the rendering of the roblox engine. Or you can also measure the time between each time you update the ImageLabel (this is called the deltaTime/framtime), and get the reciprocal of that to get the actual FPS. Now what happens without this is that RoPhotoshop can be rendering at 30FPS, but Roblox is rendering at 240FPS, and you would read the 240FPS without knowing RoPhotoshop is actually rendering at 30FPS.
Furthermore, the wording in the post regarding comparisons between OSGL/CD and RoPhotoshop is purposefully misleading. Nowhere is it mentioned that OSGL/CD are explicitly single threaded general graphical libraries. And to think that “Both OSGL and CanvasDraw Average FPS were below 3, while Ro-Photoshop maintained around 240 FPS with no lag.” has been achieved with only the addition of parallel luau is outrageous. This is an 8000% performance uplift with just the addition of parallel luau, which only adds 3-8x more workers (i. e cores). Needless to say that the hardware used when taking measurements was never mentioned either.
Finally, to be frank, this is blatantly a scam if it wasn’t obvious enough. Paying 4 figures for a half-baked roblox module should immediately raise a million red flags. And I say “half-baked” with reason, since in this quote it is very obvious that this is something incomplete from “lack of funding”, and is planned to be developed for half a decade to be released in the “2030s”.
3,000USD. 3,000USD. for “corporate, big communities”. To be taken seriously, please, consider setting the price to something sensible. If this is something that is going to be sold commercially, please note that you’re using the full trademarked name “Photoshop”.
1 Like
An OSGL-biased user commenting on this, It’s kinda obvious the results.
EditableImages had only come out of beta late 2024, and as of writing, it is early 2025. “thousands of hours” here is objectively unrealistic. The first quote is completely unprofessional and condescending, not to mention the improper grammar used throughout the post (and this is coming from a person whose english is their 3rd language).
This has been under development before even EditableImage was introduced, the clothing game development started back in 2023, regarding a bit improper grammar, It’s very obvious it’s just to bash this and being disrespectful. English is not my mother language either.
Roblox is closed-source software, and you cannot internally change LuauVM. Luau is open-source now, and I applaud the creators if they did go as far as analyzing the source code, but that would not help since you cannot change how LuauVM internally operates on Roblox. I also fail to understand how they were able to “take full advantage” of the GPU since Luau does not yet provide an interface to communicate with the GPU. The GPU is handled internally within the backend of the Roblox engine, so please enlighten me if the previous statement is wrong. And as far as I know, there is no way to uniquely identify hardware on the roblox client (if that is what is meant in the quote… as I said, phrasing is improper), nor can you actually fully utilize the CPU with Luau alone.
This takes full advantage of LuauVM, no one has said it internally changes LuauVM. There’s no need to misinterpret stuff.
Secondly, I would like to point out the method that is used to gauge and compare the performance of RoPhotoshop with competitors. This video was shared in the original post
The FPS Counter in bottom left is RenderStepped, the one in top is Roblox Stats Service FPSCounter, both are correlated.
Now what happens without this is that RoPhotoshop can be rendering at 30FPS, but Roblox is rendering at 240FPS, and you would read the 240FPS without knowing RoPhotoshop is actually rendering at 30FPS.
Ro-Photoshop, CanvasDraw, OSGL and anything else pertty much have their Rendering FPS customizable, Ro-Photoshop takes input in RenderStepped.
Furthermore, the wording in the post regarding comparisons between OSGL/CD and RoPhotoshop is purposefully misleading. Nowhere is it mentioned that OSGL/CD are explicitly single threaded general graphical libraries. And to think that “Both OSGL and CanvasDraw Average FPS were below 3, while Ro-Photoshop maintained around 240 FPS with no lag.” has been achieved with only the addition of parallel luau is outrageous. This is an 8000% performance uplift with just the addition of parallel luau, which only adds 3-8x more workers (i. e cores) . Needless to say that the hardware used when taking measurements was never mentioned either.
It wasn’t in the addition of Parallel, Parallel helped a bit, but 3 workers is max in Roblox Client anyway. Even in single-threaded version, it beat all other libraries by over 150 times in speed & performance.
3,000USD. 3,000USD . for “corporate, big communities”. To be taken seriously, please, consider setting the price to something sensible. If this is something that is going to be sold commercially, please note that you’re using the full trademarked name “Photoshop”.
We have our own upcoming games that will get released with this library, and until they’re released, this would remain like this.
You wrote a whole post full of lies, and misinterpretations.
It’s pretty sad you have to bash someone’s English because you have nothing to say other than that.
So you would rather have constant “low” FPS than only lows when you’re drawing… Questionable.
I have no experience with such things and am busy, but I’ll look into it soon.
What? Without any script I have 90-100 Idle FPS with 1 Core, and while drawing there was no FPS drop, it stayed 90-100 FPS while Drawing in Ro-Photoshop Place. However, in the latest version of the OSGL test place you sent that was specifically optimized for Basic Color Drawing, Idle FPS was same, but while drawing FPS dropped to 40-60
Ah I misinterpreted it, apologies.
It wasn’t specifically optimized for this case, no. But away from that, can I test the single-threaded Ro-Photoshop version?
It wasn’t specifically optimized for this case, no.
It was at least for most part, and it’s okay. That’s why I asked to also see other Blending Modes, Brush Strokes, Smoothening Edges as they’d make that ineffective.
But away from that, can I test the single-threaded Ro-Photoshop version?
Yes, but I’m busy these days I’ll be available from Monday, will get the place ready for you then.
Respectfully, you didn’t write the code to know the intent. I’m optimizing all of OSGL as much as I can now, and this was a good place to start (since it’s what’s being stress tested), you can personally check the repo and you’ll notice my updates already being there a couple of hours ago :). Either way - that’s irrelevant to the whole discussion so let’s leave it here.
Alright, I’ll be waiting.
1 Like
I said and I repeat, I do not mean to be rude.
You have to understand that when you reply to comments like these, try to thoroughly read before replying. Try to read and learn instead of replying back just for the sake of replying back, because I can confidently say that you have not read my comment.
I do not “bash” someone’s grammar with no reason. In the instances I said it, it’s when either something you say isn’t clear, hence I “misinterpret” it, or to point the obvious that for “3,000USD” projects like these, you should be atleast somewhat formal and professional about it. You must also know the difference between grammar and terminology. Someone who uses vague and ambiguous terms for things they have studied for “thousands of hours” does not support nor hint that the person knows what they’re talking about.
Additionally, I did not disrespect anyone here. I simply criticized. And if you really want to go down the route of “disrespecting”, remember that you were the one who harassed my colleagues for as long as I was working with them.
In fact, I actually gave up halfway through writing in the original post because I did not feel the need to write such a long criticism, so those weren’t all the points I had in mind before writing. That post was written on behalf of all OSGL contributers, and I really didn’t want to, but after you have troubled us for so long (and some of your friends on the OSGL discord server, we think?), we felt the need to write such a comment.
I hope that clears things up, and I wish moving forward that you can understand our perspectives. I really wish nothing I said hurt you too much, and I believe you can make something amazing here.
I have read your post pretty well. I haven’t troubled anyone, just because OSGL has been challenged since this module has been created doesn’t mean that. You don’t need to come here to try to create a bad narrative of this to degrade this. Technically, this is actually worth way more than 3,000 USD, not only it has the best performance anything has ever had in Roblox, but it also supports things that’s supported nowhere else, such as Rendering Canvas onto 3D models, SurfaceUI in ViewportFrame, and Vector Text Support for all Roblox Fonts. Not to mention, this is also Roblox’s first ever full image editor.
There isn’t a single ‘false claim’ about this module, everything is the reality of this. I’ve already seen many times from OSGL developers and users trying to degrade this publicly while it’s a whole different story privately, trying to figure out how this works and DMing me about contribution. While I’d love to make this open-source and help people for free, we’re currently holding off because it would create competition with our full image editor, which is set to launch alongside our upcoming games later this year.