Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Deno and Chrome canvas generation differ for the dataURL as well as picture size(in kilobytes) #50

Open
pxCaptcha opened this issue Jan 26, 2023 · 3 comments
Labels
help wanted Extra attention is needed

Comments

@pxCaptcha
Copy link

Code.zip

The we.js file and test.html file are identical, when its coming to the calls for creating the canvas

ctx.clearRect(0, 0, 300, 300)
Fonts.register(Deno.readFileSync("C://Windows/Fonts/micross.ttf"), "Microsoft Sans Serif")
console.log(Fonts.families)
ctx.font = "10px Microsoft Sans Serif"
ctx.lineWidth = 1;
ctx.shadowColor = "rgba(0, 0, 0, 0)"
ctx.miterLimit = 10
ctx.strokeStyle = "#000000"

This part can be ignored in the we.js file, as these values are exactly like chrome uses them, we setted these values before, hoping it would fix the issue, but it didnt.

window.canvas and the canvas from deno it self have the same settings by adding this stuff, but probably somewhere its not matching for the skia part it self.

https://prnt.sc/pjG5YweCOTvC

Here again u can see the size difference

image
And in this image on the left is the browsers data url, on the right its deno. Same code, but way shorter output also resulting in a smaller file when u save the .png

More info:
Both pictures are .png
The font matches to browser
The settings we were able to access, match all

thank you for your time!

@DjDeveloperr
Copy link
Owner

DjDeveloperr commented Jan 26, 2023

I have tried tweaking some Skia options but got no difference in renders. I think the issue is more of a rendered image does not match Chrome's, rather than the size of encoded PNG, which is going to differ almost always between Chrome and Deno.

However, I don't notice much difference between the two renders either. As discussed previously on Twitter, is it really required to compare hash of these base64 encoded URLs with browsers? To me, it doesn't look much reasonable. This sort of exact behavior is very hard to achieve.

Also tried rendering on both CPU & GPU. Actually, GPU one produced a bit different render but it was actually more small than CPU one...

image

@pxCaptcha
Copy link
Author

Isnt it weird tho, that even on gpu, still yet its so much smaller? How can the chrome version have 10 more kb, and so much more dataurl text, if everything is matching properly? What makes the size of a png rendered? And how could we get closer to browser(w/o browser haha)

@DjDeveloperr
Copy link
Owner

There is a slight difference between the stroked lines between Browsers and Deno Skia Canvas. Which is probably causing the image to be little different, and rest depends on PNG encoder. I don't know specifics of that. I tried the same example with other canvas libraries in Node.js ecosystem and they also produce results similar to Deno. Firefox too produces 2KB smaller image than Chrome. I think browser is just using some different option in Skia here. Lesser the size of encoded PNG, of course the data URL which is just base64 encoded PNG will be smaller too. It's not really weird, getting close to browser just requires more time and effort.

This issue isn't really high priority right now, so I don't have enough time to spend working with Chromium source.
Though, if anyone wants to take a look, it's always welcome.

@DjDeveloperr DjDeveloperr added the help wanted Extra attention is needed label Jan 27, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
help wanted Extra attention is needed
Projects
None yet
Development

No branches or pull requests

2 participants