Replace PNG UI elements about gdbrowser

[GDColon]

h

[GDColon]

I have no idea what the hell this chat is anymore so here's the one TRUE vector

[0x1DEA]

I would first get the player shapes from /icons and turn them into multi-layered SVGs. This way you can save on the amount of files into 1 file per shape. For color changing I could use simple JS or a library such as SVG.js to change the colors within the icon generator. It's very light and easier than manipulating PNGs. Second, I would convert as many UI elements from /assets as possible. I tested it and the conversion is worth it for the files. Even the small images for social media went down ~2kb in size. Manually re-creating them will take longer but will make the size even smaller than using an automatic SVG converter. In the site, the files will simply be replaced. The dimensions of the bitmap files will be included in the SVG file itself so there shouldn't be many problems with scaling.

[0x1DEA]

Also I neglected to mention regarding normal handling with icon.js, SVGs are much easier to recolor programmatically since SVGs are text and objects in the image have an easily changeable color value which is very useful for player icons.

[R3Ked]

sorry but what is a svg

[0x1DEA]

@siky112 An SVG (Scalable Vector Graphic) is an image format that instead of being made of pixels like a PNG (or any other type of raster graphics) is made out of plaintext. Here is an SVG file on my website. Click here. you can view this in your browser as an image. But you can actually open up the file in a text editor and it is in XML format.
<svg height="210" width="400"> <path d="M150 0 L75 200 L225 200 Z" /> </svg>
Since it is in this format it is much easier to edit and is very popular on the web.

[GDColon]

I've worked with vectors before, but I just didn't use them for GDBrowsers since I just ripped all the sprites directly from the game files. RobTop actually said that he makes all his GD stuff in vector but converts them to PNG afterwards and it hurts to read it every time. Anyways, I think it's a great idea but I'm mean and stubborn and personally feel like leaving it as PNGs for my own efficiency. I know I know, I suck 😛

[0x1DEA]

If I were to make the changes would you consider accepting the pull request?

[GDColon]

I personally think it's not worth the trouble. Can you go over what exactly you would change? (and how)

[101arrowz]

+1 I'm gonna side with SeeBeyondDev on this one. SVGs are indeed much better suited for this kind of thing (static icons), and there are tools to convert PNGs to SVGs.

For icon generation, unfortunately, we can't actually use SVGs unless we completely redesign icon.js. Jimp does not support SVG output. We'd have to use something like node-potrace to trace the PNG into an SVG.

The best solution for icon.js is to recolor on client side. If we use SVGs, it's actually much easier to do on client than on server side. Also, cropping is super simple, since SVGs are actually very similar to HTML elements and have properties that can be modified to adjust height, width, etc. This also means less server load and scaling without pixelation at any screen resolution.

[GDColon]

Buzzkill Punctuation here - I'd rather not change icon.js since I really want them to be PNG images, and also want the icons ripped directly from the game files.

[101arrowz]

Any reason in particular that you want them to be PNG? Rendering an SVG to a PNG is much less computationally expensive than the reverse, so if you wanted to offer a PNG option in the API, we could do that while still creating the images in SVG originally. The PNG option would just have the server render the generated SVG to a PNG of size myWidth by myHeight.

Also, if you wanted them directly from the game files, you shouldn't have merged my PR with speed optimizations. I shrunk the file sizes of all the PNGs by compressing them. This is really similar, it's just a different format of holding the image data.

I actually feel quite strongly about implementing this one. It's a very good idea and would solve a lot of your server lag issues. Plus, it renders better across devices because it's a vector. Plus, it's smaller file size. The biggest plus, I can make a tool to automatically convert any PNGs into SVG, so if any new icons are added we don't need to do any manual work.

[GDColon]

Main reason is that it's easier on the client. It's much better if they can save the icons as PNGs than vectors that can't be edited or pasted into programs. I just feel like this is overall too fancy of a change for my liking.

[101arrowz]

Who said SVG files can't be edited? More than that, why do users need to copy images from GDBrowser? If they need a PNG rather than an SVG, they can use the hypothetical PNG option when calling server side.

[0x1DEA]

TL;DR

• Image processing on the server can be a bottleneck on performance
• Images can be processed as SVGs then exported and be saved PNGs for convenience if thats what you prefer.
• Optionally if needed we can have advanced options for exporting such as filetype or size

What operations are handled by the server? Perusing the package.json I see you are using jimp. Why is the server handling images? This is a major disadvantage in the event of high traffic the server is overloaded. Ideally, in this type of application intensive processes like this should be handled by the client. May I also ask where this node server is being hosted? I hadn't noticed before but this can be a large bottleneck to performance. I think it would not only be beneficial to 1. Move as many intensive processes such as image processing off the server load as these tasks can impede the server when it is trying to complete requests. 2. And Arrowz, are you suggesting that images be exported as SVG by default? Because on that I actually disagree as exporting as a PNG would be more convenient. We can for sure have imaged be exported as a PNG as conversion from SVG to PNG is trivial.

[GDColon]

I'm starting to get really lost here. I'm still not sure about this change, probably because I don't like code I don't know, and because I just don't like change. I'm sure it's good. If you were to make a PR with all the changes you brought up, can you explain what it would look like? (pseudocode would help)

Really sorry if I'm being super annoying/stubborn/infuriating. I am very aware of this issue and am looking for a fix. I just really like having things exactly how I want them, I guess. also all your opinions are wrong

[101arrowz]

Default options are trivial to change. So sure, the default behavior can be PNG, and SVG can be an option. That SVG option will save some server resources and be used by default by GDBrowser if these ideas are added.

@GDColon I'll work on this SVG stuff and submit a PR. If you really REALLY hate this idea then ^{you're a boomer but} let me know, and I'll submit a PR using sharp, which is 40x faster than Jimp. I've used it, it's super easy to work with.

<joke>
also you should learn new things instead of trying to make everything work with only what you know

also jquery is shit and i'm still salty that you didn't accept my jqueryless pr
</joke>

[GDColon]

hahahaa

but yeah you might wanna go over what exactly you're doing in the pr before i just shut it down like the monster/boomer i am

[101arrowz]

Yeah let's do more of this conversation stuff before I spend cough 5 DAYS WORKING ON SOMETHING FOR IT TO GET REJECTED AAAAAA cough.

So this will entail removing all Jimp references and replacing them with SVG manipulation. This could be done with something like simple-svg-tools. I'm not sure of the specifics but I can figure it out. Alternatively, @SeeBeyondDev could do it, since he seems to know more about Node.js SVG manipulation than me.

As for the sharp idea, it's very easy to change. I just replace all Jimp calls with the equivalent function in sharp. I've done it before with parcel-plugin-pwa-manifest, so this will be easy for me. I could do that alternatively. Your call.

I think the SVG idea is better for versatility, although both may be equal in speed.

[0x1DEA]

@101arrowz nonono lets not involve nodejs in this. SVG manipulation can be done just fine on the client side as well. One of the main points of SVG switch was that it was an easier format to edit since it's XML and it could be done on the client side. Also, colon I'd be glad to explain my proposed changes just give me some time on that pseudocode PR mockup since I have to see some of the places I would need to modify.

[101arrowz]

Colon, your speech is so moving and inspiring. I could never have said something as meaningful and incisive as you.

@SeeBeyondDev I agree with that concept, but wouldn't that mean we would have to use a separate API for GDBrowser client side (which would need an SVG string and recoloring data) and a separate one for the general public to use (PNG output)? That seems complicated.

Actually, never mind, we could just have both be exposed to the public, with rawSVG being an optional parameter in the request to the server that GDBrowser would use.

[GDColon]

lmao that's one of my favorite videos on youtube, good taste

[101arrowz]

So, beyond memery, what do you think of SeeBeyondDev's idea?

[GDColon]

Honestly, you two lost me a while ago

[101arrowz]

🦀 cologne's sanity is GONE 🦀

I'll make the PR with sharp so we have a quick fix. I don't expect that SeeBeyondDev will be able to understand the spaghetti quickly, so I'll just do it now (only somewhat kidding).

[0x1DEA]

@101arrowz What do you mean separate? We just export SVG as a PNG. We don't need to manipulate the PNG, it's just for exporting. And what do you mean the general public? What is the opposite of that? Why do you want the server to be used for editing images?

[101arrowz]

Here's the deal. If you are okay with allowing server-side to recolor the SVGs, which isn't even that hard, then we can render it to a PNG and send to client. If the client requests an SVG, we send the SVG without rendering.

If you want the client to recolor the SVGs, how do we continue exporting as PNG? We need color data in the SVG for that. We'd have to have completely separate pipelines if the request is made from GDBrowser or from a developer who's calling the API, expecting a PNG. We'd need to continue the bad Jimp system for the normal API caller, and have the better system return an uncolored SVG along with color data to GDBrowser. It's overly complicated. That's why SVG recoloring on server side is optimal.

By the way, using Sharp turns out to be difficult for recoloring specific colors. So that's coming but it might take a bit. I'd prefer if @SeeBeyondDev would do this instead though, since SVGs are better than continuing to use PNGs but in a less bad way.

[0x1DEA]

OOOH I understand where the confusion was! Okay yeah I get where you are coming from. Yeah returning a PNG is good for the api. but perhaps we can have a flag for the api that returns an svg when on the client so the client can have color changes be immediate instead of having to wait for the server to do it. So a regular api user can keep their PNGs but since we can offload work onto people accessing the actual webpage we can load an asset once and recolor there. I hope that’s clearer.

_{Sent with GitHawk}

[101arrowz]

colon you are truly evil, that image should have a trigger warning, my second-to-last braincell died watching that movie and my last one is about to disintegrate seeing that character do the T pose

So I'm gonna leave resolving this issue to @SeeBeyondDev, since I'm not sure how to implement this system in a clean way. Thanks for contributing to the project!

[GDColon]

Come on man, the first movie wasn't that bad. They just started to capitalize on the minions after that.
Vector! That's me! 'cuz I'm commiting crimes with both direction and magnitude! Oh yeah!

[jbmagination]

this is the best thread. but really, vectors would be great