/tech/ - Technology

Miscellaneous notes:
- There won't be tabs because that's a big departure from how MS Paint works, and I don't want to add an entire row to the UI for them. I want the UI to ideally take less space than it does in MS Paint, not more.
- Import/export for more file types. Ideally use some kind of plugins to handle file formats so they can be added/removed without having to modify the main program.
- I'd like to be able to edit .gif animations, but I'm not sure what kind of UI should exist for that. Maybe just a list of frames and their settings. Maybe that's out of scope for this project though.
- Proper (but minimalistic) transparency support so you can open/save transparent PNGs. Also, better support for transparent to/from clipboard.
- Most settings should be saved automatically, for example if you switch to a bigger brush, it'll be active next time you open the program.
- Scroll wheel scrolls up/down, Shift+Scroll scrolls horizontally, Ctrl+Scroll or Alt+Scroll will zoom the canvas.
- I'm unsure what to do about recently used colors. MS Paint has them at the bottom of the swatch list, but I never use them personally and they waste a lot of space.
- Similarly, I'm not sure what's the best way to modify swatches. Maybe Shift+Clicking will set the current color into a swatch?
- The top bar is a little wider than MS Paint's top bar because the color sliders just take a lot of space. I think that's a worthy sacrifice though.
- I had the idea of potentially saving information into PNG metadata. For example if you enable a 16x32 grid, you wouldn't have to re-set the grid every time you open the file. The main reason I thought about it is that I need a better spritesheet editor, I could add some kind of spritesheet plugin to this program and save/load the spritesheet information to/from PNG metadata. I haven't thought about it much beyond that.

pixelated.webm
[Hide] (245.5KB, 680x330, 00:10)

color_replacement.webm
[Hide] (24KB, 150x110, 00:05)

The videos don't seem to work well on my browser so here's webms.

>>14096
>- I had the idea of potentially saving information into PNG metadata. For example if you enable a 16x32 grid, you wouldn't have to re-set the grid every time you open the file. The main reason I thought about it is that I need a better spritesheet editor, I could add some kind of spritesheet plugin to this program and save/load the spritesheet information to/from PNG metadata. I haven't thought about it much beyond that.
I don't know if that's a good idea in terms of privacy. You should make that optional.

>>14095 (OP) 
I like your idea. The GUI design looks pretty good.

But would it be too crazy if it would support Lua extensions?  Lua is small and lightweight language, and it's designed to be well suited for embedding into other programs. My idea is to  let the user program the whole Paint application with Lua. Lua would give complete access to all features and you could choose color or move the brush inside the canvas. I think it would be cool if you could use  turtle graphics with a extension written in Lua. Then the user could make (generate) a part of the image using turtle graphics and then edit it using regular paint features.

GPFi9pTXkAEO7KW.jpg
[Hide] (59.5KB, 849x676)

>>14098
>storing grid dimensions
>privacy
I'm not sure what kind of information you think might be stored with that but I don't see how it would matter. It's not going to put your GPS coordinates in there. It'll be like, the tile size for a spritesheet. It's not going to be something that people couldn't figure by looking at the image right?

>>14096
>>14095 (OP) 
OP, I'd recommend you also look at GraphicsGale as it achieves many of the same things as paint, in a similar lightweight footprint, but some things are implemented in superior way. For example, having a color palette is easy to do, allows you to quickly edit real data stored in BMP and PNG files, and offers a better user experience for color replacement and the like. MSPaint's recent colors is useless by comparison. 

Of course you probably don't want to recreate all the advanced features of GraphicsGale since you're aiming for minimalism, but they're still good for inspiration. For example, there's an edit history timeline which is fucking amazing for A/B comparing your changes to a picture. There's some options for displaying grid guides for tilesets. A tile view to see whether repeating tile edges loop properly. Of course it also has animation/layering features, but I hardly use those. You don't want to add all this crap, but a lot of the design choices of GraphcisGale are rock solid. 

https://yewtu.be/watch?v=tXvLjXAL8x4

I would love to have a Paint program that's cross-platform and works natively on Linux, I couldn't find any program so far that replicates the MS Paint experience and GIMP is overkill... My personal wishlist would be:
>lightweight
The program must be small and quick to start, just like the original MS Paint. Avoid slow operations at startup such as looking for fonts/libraries/executables.
>easy to compile
Please please PLEASE avoid dependency creep. Massive libraries like Qt, GTK, and GNU products in general are beyond bloated and a pain in the ass to compile, plus they break shit all the time. Stick to the tried and true image libraries (libpng, libjpeg, giflib) and a robust graphics library (SDL), you really don't need anything else.
>non-GPL license
TL;DR GPL licenses are legal minefields and will ultimately hurt the adoption of your program. Better choices are the MIT, BSD, and Mozilla licenses.

For your first version, focus on the fundamental features of MS Paint which have existed since the 1990s. I would personally suggest postponing the tricky features for later, such as font discovery/rendering, transparency, layers, anti-aliasing, and metadata manipulation.

>>14100
>I'm not sure what kind of information you think might be stored with that but I don't see how it would matter. It's not going to put your GPS coordinates in there. It'll be like, the tile size for a spritesheet. It's not going to be something that people couldn't figure by looking at the image right?
The problem is not the information itself, the problem is that it makes the file more unique and traceable, akin to an image's unique filename (for this one jschan has a "Strip Filename" option but it's flawed >>14034 ).

>>14101
>I couldn't find any program so far that replicates the MS Paint experience
Paint executable on Wine

>>14104
Wine is abysmally slow to start even with a pre-created prefix + doesn't always read image data from the clipboard.

>>14098
It would be optional of course. When you export an image, you could choose between "PNG" and "Paint2 PNG". I'll have to add a setting that defines what to do when you press Ctrl+S though, I don't want it to ask every time.

>>14099
Sounds like it wouldn't be useful enough to be worth the effort and added complexity, bigger image editors are probably more suited for that kind of thing. The program will be open source though so maybe someone can add it.

>>14100
GraphicsGale is way more complicated than what I'm going for, but I'll look in case there's interesting ideas. The main limitation is that I don't want the UI to become more complicated or take more space than MS Paint's UI, otherwise MS Paint will have an advantage over this program which kind of defeats the point. If there's features that can be tied to hotkeys or configurable settings, that would be nice.

>>14101
>small and quick to start
Starting and closing and responding to input instantaneously is one of the key appeals of MS Paint in my opinion, so that's given.
>dependency creep
I don't expect to have any dependencies other than some third party library for font rendering. I'll need SDL on Linux, hopefully someone can eventually help me replace it with custom code because it's a huge dependency and yet the only thing I need from it is opening a window and taking keyboard/mouse input. I can do that myself for Windows but not for Linux. As mentioned the plan is to separate each file format into a separate "plugin", so for example all the dependencies (if any) for .avif files would be isolated to it's own plugin and you can just ignore/delete it if you want to.
>GPL licenses are legal minefields and will ultimately hurt the adoption of your program. Better choices are the MIT, BSD, and Mozilla licenses.
What do you mean by "adoption"? It's a desktop program, you install and use it by itself. I don't want someone to adopt the source code if I'm being frank, if someone takes what I spent time and effort working on and gave out for free, then they should have to give it out for free too or else pay me. Permissive licenses make more sense for libraries because they're meant to be integrated into someone else's program.
>postponing the tricky features for later
I don't think there are any. The only thing I'm uncertain of is support for different file formats, I'll have to get new libraries for them.

>>14106
>hopefully someone can eventually help me replace it with custom code because it's a huge dependency
What about Raylib? it's similar in basic concept to SDL and highly modular.

>>14106
>it's a huge dependency and yet the only thing I need from it is opening a window and taking keyboard/mouse input.
You can very easily compile SDL yourself and enable only the subsystems that you need (i.e. video and input) in order to significantly reduce the size, I've done this on both Windows and Linux and can gladly assist you. The cost of writing your own video/input code is that you'll have to deal with all the annoying platform-specific quirks that SDL has spent the past 25 years handling, instead of focusing entirely on the paint program itself.
>some third party library for font rendering
FreeType2 should come in handy here, or if that's too bloated try stb_truetype.
>the plan is to separate each file format into a separate "plugin"
Could you elaborate on the mechanism for that? Are you going to rely on dynamic libraries / DLLs or will you make the program's image decoder fully scriptable?
>What do you mean by "adoption"?
I'm mainly talking about package maintainers compiling and distributing your program on Linux distros, BSDs...etc. Plus any user who wants to contribute code.
>It's a desktop program, you install and use it by itself
That's true, however you will be linking external libraries into your program and/or using external decoders... If your program is GPL then you can only interface with code that is under the same GPL version or one of the permissive licenses that are "GPL compatible". You can't mix GPL2 and GPL3 code for example because both licenses are incompatible, same goes for AGPL and LGPL versions.
Whatever license you choose, the best piece of advice I can give you is to read the license text yourself before applying it to your code.

>>14107
>Raylib
IIRC raylib depends on OpenGL, which is an unnecessary dependency for a 2D paint program.

>>14107
I haven't looked into it. My impression is that it's mainly a rendering library, so it may be tied to some things that I don't want to be tied into. I'll check it out when it comes down to it.

>>14111
>compile SDL yourself and enable only the subsystems that you need
Maybe, but the way I see it, if someone can replace it then there's no advantage to keeping it since nothing you can do to SDL will make it as lean and simple and hassle-free as a couple custom functions. I'll start with SDL anyway though and maybe nobody figures out how to replace it so it'll end up staying.
>FreeType2, stb_truetype
There's a warning at the beginning of stb_truetype.h to not use it for untrusted files since it doesn't validate offsets in the file. For similar reasons I can't use stb_image to load png/jpg/etc; STB libraries aren't meant to be full-featured. Freetype is what I was planning to look at for text.
>plugins
>Could you elaborate on the mechanism for that?
With 2 function calls you can get function pointers from any .dll file on Windows. I haven't done it on Linux but it has equivalents (dlopen() and dlsym()). The plan is that the program by itself will only support .bmp files, but there's a plugin folder that the program loads any dynamic libraries from, and the plugins can then tell the program about additional file formats and provide relevant encode/decode functions. I'm not familiar with what conventions Linux has, like is it taboo to just have a folder in the program's own directory for config files and plugins or should they be somewhere in a centralized place? And what happens if you make an appimage out of this, will that break the whole idea? I'll try to set things up in a way that makes them easy to change.
>licenses
Krita and Gimp are GPL and most other editors are proprietary, did they all write custom encoders and decoders from scratch for all the file formats they support? Anyway getting bogged down on licenses before there's even a program is a waste of attention. The plugins will be separate anyway and can be licensed differently, I can add an exception if GPL doesn't allow bundling the program with something else (I'm pretty sure it does though), I can pick a different copyleft license or even make up my own.

>>14112
>dlopen() and dlsym()
I'm okay with this, as long as there's an option not to use it. As in, it should be possible to compile the program with all encoders/decoders linked directly into it. (i.e. static linking libraries)
>is it taboo to just have a folder in the program's own directory for config files and plugins
Not at all, in fact this makes it easier to turn your program into an appimage. Although you might want to have additional config paths, so users don't have to touch the program directory if they don't want to or are unable to.

>>14114
>as long as there's an option not to use it
Unless you have a good reason why, no. Is there an advantage for them being static?
1. I can't think of how to make it optional without duplicating all the code from all the plugins.
2. It would increase the complexity of compiling the program (and explaining to users how to compile it) because now there's 2 different ways to compile plugins.
3. You'd need to re-compile the plugins and whatever bloated ass dependencies they have if you want to modify the program.

>additional config paths
How would you define them? Or is there a list of common paths that people expect to have?

>>14095 (OP) 
>curve tool
probably the most neglected but very useful tool
https://www.youtube.com/watch?v=4HpH1pZSQvc

this is getting more pixel art tier but
>easy way of exchanging colors or even going so far and painting 'palette index' instead of raw colors
>larger brush size could be filled with swatches/patterns, making it easier to do cross hatching / dithering across large areas
>able to switch colors mid painting
>brush stabilization to imitate a rigging brush

>>14116
>curve tool
That's in MS Paint so adding it into this is obvious.
>exchanging colors
Paint bucket will have a color replacement mode, and the eraser tool can be used to erase/replace a specific color with right click (MS Paint already has this, although it feels like a secret).
>painting 'palette index'
It's possible, but I feel like it's not worth it: it's a negligible convenience which creates relatively high complications for the UI and such. The main advantage is when using a gradient tool since it auto-palettizes the gradient, but even that feels super niche for me.
>patterns
There will be dither patterns, it would be pretty simple to extend that feature to general patterns. Maybe you could even draw some pixels, select them, and then right click to add it to the patterns list.
>switch colors mid painting
Swapping Color1 and Color2 while drawing will probably be possible by nature, although I don't see the purpose.
>brush stabilization to imitate a rigging brush
I don't know what a rigging brush is, but stabilization is a good idea.

>>14115
>Is there an advantage for them being static?
The eternal debate on dynamic vs static linking, especially on Linux, is a long and convoluted one. I probably shouldn't derail the thread with such a debate... With that being said, I think the quirks of both approaches will ultimately become clear to anyone who tries porting and distributing software on Linux.
>is there a list of common paths that people expect to have?
On Linux ~/.config/your-app-name is the standard path for application-specific configs, so if you're going to support multiple config paths check .config first before falling back to the program's directory.
As for Windows, here's a quick list: https://www.majorgeeks.com/content/page/appdatalocallocallowand_roaming_folders_explained.html

>>14121
>eternal debate on dynamic vs static linking
I'm pretty sure that debate is based on 2 things: requiring the installation of third party dependencies, and conflicts between versions of said dependencies. Neither is relevant because the plugins will technically be a part of the program and can/will be bundled with it, you won't be installing them and they can't conflict with anything else.

Once you have a working version, I'll make the logo.

icon.png
[Hide] (137KB, 453x523)

>>14135
Sorry the logo already exists

This is probably a long shot but I'll ask anyway: what would be a good technique to avoid drawing unnecessary pixels?

MS Paint does not use the GPU at all, so I want this program to be efficient even with software rendering. I already have a way of only rendering the areas that have changed, so the biggest remaining cost as far as I can tell is from drawing over the same pixels multiple times. For example, there's the canvas, canvas has a gray background behind it, and then the window itself has a background color. That means that for like 85% of the window, you'll be rendering over the same pixels 3 times, which is a huge waste of performance. There's similar lesser issues elsewhere.

One easy thing you can do is just hardcode the backgrounds so that you only fill from the sides of the canvas area. It's too hard to hardcode something like that for every element on the UI, but that at least takes care of the biggest cost.

Is there a better way? I was thinking of some kind of rectangle masking system; large opaque elements add a rectangle into a list, and all elements will avoid drawing over mask rectangles that are above them. I'm not sure how that would work exactly, but it's probably worth investigating.

>>14138
That is the kind of optimization the graphics library or the GPU should be doing, not the developer.

>>14140
It cannot.
>GPU
Don't reply if you didn't read the post.

>>14138
You can "cache" certain areas of the window that you know are not going to (or are unlikely to) change; create a transparent SDL surface, render the unchanging areas onto it, then blit it to the screen using BlitSurface as many times as you need. Blitting is a fast operation that's done in software, no GPU necessary.
For solid color areas specifically you can use FillRect, which does a fast flood fill of a rectangle, also in software.

paint.webm
[Hide] (4.9MB, 1130x750, 00:42)

ui.png
[Hide] (169KB, 1101x824)

Just posting an update. Basic functionality is in to the point where it at least kinda works like a paint program. Lots of stuff still missing though.

I didn't do this intentionally, but the UI layout is mostly editable from a text file as a consequence of how I've made my UI system. I think that's kinda cool so I might expand it so that you can edit all the visual style definitions and stuff from a text file too. Could be cool if the UI was very customizable.

>>14100
Perhaps unexpected, but the most interesting idea I saw in GraphicsGale was the tooltip that pops up when you hover over color swatches, so I added tooltips to everything (ironically there's no tooltip for swatch RGB values yet though). Most of it's features seem to be for animation so I can't get much out of it. Locking states in the undo history window seems nice.

--
I'm genuinely baffled how MS Paint can accomplish the rendering performance it does. If you zoom in as much as you can, select as many pixels as you can see on screen, and then move the selection around, the screen appears to update very smoothly even if you have transparency enabled. What this suggests is that MS Paint can render a full-screen worth of pixels while accounting for transparency without any apparent lag. It may be pre-rendering pixels somehow though because the performance tanks to shit if you try the same at 100% zoom level. But similarly, you can scroll sideways without any apparent lag, even at 100% zoom level. My program is usable but it clearly slows down if I move the canvas while full-screen. Only 1 thread is active in MS Paint so it's not doing multi-threaded rendering either.

I doubt it, but it may somehow be leveraging dwm.exe (desktop window manager, which afaik handles window compositing to the screen) which does use the GPU for rendering. If I draw circles with a brush, the GPU usage of dwm.exe in MS Paint jumps up more than it does in my program. That might also be because MS Paint is updating the window less efficiently than I am, but that would make it even more confusing how they're accomplishing such performance. It might ALSO be because my own rendering is slower so dwm has to update the window less often though.

Another possibility is that rather than re-rendering a portion of the window, they have lots of special hard coded optimizations, like a hard coded way to scroll the canvas pixels horizontally in an optimized way, another for vertical scroll, etc. I can't cheat scrolling though because of the transparency grid. Also SIMD, for example I can kind of imagine a hard-coded way to render the canvas at 8x zoom level by spreading a pixel into a 256-bit SIMD register and copying that 8 times vertically. I'm not too confident about my SIMD skills, I never even managed to do proper alpha blending with it.

>>14161
That looks great, when are you going to share the source or binary? I'd love to test this on my machine. 
>I can't cheat scrolling though because of the transparency grid
This got me thinking if transparency is overkill for this program to begin with... If you're not handling partial transparency anyway you could draw transparent pixels as a solid color, while allowing the user to easily remove this color in the exported image. It could be as simple as:
<import image and replace transparent pixels with a random color
>now you have a  regular 24-bit image, let the user edit it like he's used to in classic mspaint
<in the export dialog, let the user pick a color to become transparent in the entire image
I hope that made sense.

>>14164
I feel like there's no point in sharing it until you can actually use it for something, for example you can't load or save files yet and most of the tools don't do anything. But here's the exe if you want to try I guess: https://files.catbox.moe/ytslvy.zip
I'll make a proper release with source code when most of the functionality is in.

>got me thinking if transparency is overkill for this program to begin with
I think that's one of the big things lacking from MS Paint, you just can't open transparent images without screwing them up, so I want to change that, the program already supports full color transparency anyway. I'll add an option to turn off transparency (and probably keep it off by default unless you open a transparent image) so it works more similarly to MS Paint, it can probably be used for extra optimizations too.

>in the export dialog, let the user pick a color to become transparent in the entire image
Yeah that can probably be added pretty trivially. That said, in theory anything can be added, but for a program like this it's better to choose carefully. The paint bucket will have a color replacement mode which can be used to do that, so adding another setting for it is arguably just clutter and makes exporting more confusing.

GIF doesn't have real transparency, you have to select one of the colors from it's color palette to represent emptiness, but even for that I think it makes more sense to do the inverse of what you're suggesting: edit the image in transparency mode because that's how you're supposed to see the image, and then in export options you select what color to replace transparent pixels with.

"TFF Paint" is the working name by the way, it stands for "Tiny Fast Free Paint" and sounds similar to "MS Paint" which it's supposed to replace. Suggestions for a more clever name are welcome.

>>14177
Most of the names I thought of were already used but what about "Zippypaint"?

Paint Tool SAI 2 is a great lightweight MS Paint substitute, it could work as a frame of reference.

>>14183
Wasn't that more of a digital art-focused thing?

>>14184
it is but it has every single feature that MSP has and little else.

>>14176
>here's the exe
Awesome. I just ran it through wine and it was blazing fast to start, great work there.
Here are some comments and suggestions:
- The keyboard shortcuts for vertical/horizontal scrolling and zooming are a great addition, but I would like to be able to rebind the keys. Specifically binding [Ctrl]+[MWheel] to zoom as that is the standard in GIMP and other graphical tools. Adding middle-click to drag the canvas would also be nice.
- I'm not a fan of the program taking over window decorations (window borders, close/minimize buttons...etc). I would very much prefer my OS to handle that, because user programs are unlikely to know what gestures and keyboard shortcuts I have set for window control.
- Is it possible to scale the UI? A simple nearest-neighbor 2x scaling of the font and icons would help make the UI much more legible on my screen. I tried scaling the PNGs in the tffp directory but the result wasn't quite what I expected.
- This is more of a nitpick; to change the value in a color slider I have to click and drag the handle, but I would also like to just click somewhere on the slider and have the handle automatically move there.

>>14177
>Suggestions for a more clever name are welcome.
"TFF" sounds awfully close to "TIFF" which is an image format. I would suggest "tinypaint" or just "tpaint".

>>14182
Zippy is a compression library made by Google and sounds related to .zip, my immediate feeling is that it's confusing. Maybe we can do a poll for the name at some point if there's no obvious best name.

>>14191
>close to "TIFF" which is an image format
Yeah definitely sounds too much like TIFF Paint now that you mention it. I'm also concerned that "TF" is used as a shorthand for transformation fetish. It could be rearranged into something like FT Paint (Free Tiny Paint) too, although now it has become FTP (file transfer protocol). I actually wouldn't mind naming it "PNG Paint" because PNG is the most suitable file format for this program.
>I would suggest "tinypaint" or just "tpaint"
Doesn't sound very distinctive. Reminds me of browsing some alternative program websites and scrolling by generic names. I also have a personal bias against Tpaint because my online nickname has a big emphasis on the letter T, feels like I'm a narcissist naming programs after myself.

My original idea was "M-5 Paint" just because it looks like MS Paint, but I couldn't come up with any other justification for it. Personally I like the idea of somehow using a similar format for the name as MS Paint because this is very obviously a clone of it, but it doesn't have to be similar in any way.

>[Ctrl]+[MWheel] to zoom
You can zoom with just mouse wheel though, what would you bind to a regular mouse wheel action then? I can do at least simple rebindable keys. It's easy to change a hard coded key to a customizable key, but it's more complicated to support arbitrary hold/press/wheel combinations. Never done it so I'm not sure.
>middle-click to drag
The move tool's tooltip already mentions that, I just didn't implement it yet.
>not a fan of the program taking over window decorations
Yeah I'll probably add an option to disable the custom window. I like the custom window because it's easier to use the space efficiently and add extra options/features/visuals, but it's very hard to reproduce all the OS-defined functionality (and layout, for example sometimes the top-right buttons are on the left side), especially on Linux which is more varied and customizable.
>Is it possible to scale the UI?
The plan is to switch to a proper font instead of using the bitmap font, but I'll need to set up and learn FreeType first. With that it'll be possible to scale the UI to any percentage, I'll scale everything else along with that. I don't know about Linux, but Windows will scale the program in a very blurry and ugly way if the OS-defined UI scale is increased, in order to fix that the program needs to be made "DPI-aware" but I couldn't get it to work last time I tried. I'll do all of this at some point.
>I tried scaling the PNGs
The icon definitions are very hard coded at the moment, I want to make them fully customizable. It should be possible to define an arbitrary size icon which will be scaled to the destination size, but it should also be possible to make sure the icons are pixel-perfect like the ones currently in use. I'll have to think about how to scale things.
>to change the value in a color slider I have to click and drag the handle
Good find, I didn't even notice that. I don't consider this a nitpick at all, I know the term "UX" has a bad reputation but fixing this kind of things is what I consider to be true UX design.
There's other problems with the HSL sliders that I'll fix later (the HSL values are always evaluated based on the active RGB color, so gray colors get stuck at 0 hue and saturation).

>>14192
What about naming it BasedPaint? Just kidding, of course, but some people could really like that idea.

>>14195
I don't have a problem with the word itself, but calling yourself based is unbased.

>>14192
>My original idea was "M-5 Paint" just because it looks like MS Paint, but I couldn't come up with any other justification for it. Personally I like the idea of somehow using a similar format for the name as MS Paint because this is very obviously a clone of it, but it doesn't have to be similar in any way.
M$Paint in reference to how some GNU/Linux types call Microsoft M$?

>>14197
it makes me think of grifters like that one youtube tech guy who said that imagination is satanic

>>14192
>feels like I'm a narcissist naming programs after myself.
No shame in that. Plus you wouldn't be the first; check out "mtpaint" by Mark Tyler.
>I can do at least simple rebindable keys.
That's pretty much what I had in mind. Actions that require a mouse wheel will keep requiring it, but the modifier key (the key that must be held down) can be changed or removed.
>the program needs to be made "DPI-aware"
IIRC all it takes to turn off the blurriness on Windows is the SDL_WINDOW_ALLOW_HIGHDPI flag which you pass when creating a window. I can test it in a VM later and let you know if it still works. 
>it should also be possible to make sure the icons are pixel-perfect
Consider vector icons if you're going for non-integer scaling, otherwise a simple upscale of the current icons should be enough IMO.

Call it SleepyPaint for the branding :^)

>>14209
You're joking but I actually like this idea. It may even be featured in Sleepy Station magazine

>>14199
That would be annoying to search for, might cause issues with filenames and URLs and such, is hard to vocalize without it just sounding like MS Paint, gives undue attribution to Microsoft and is an anti-description of the program because it's supposed to be FOSS and work on Linux too.

>>14208
I was thinking of using vector icons, but vector images look kinda shitty when they're tiny, and I don't want to add some bloated vector rendering library as a dependency just because of them.

I don't want to use SDL on Windows because I'm familiar enough with the Windows API. I've tried SetProcessDPIAware() but the issue is that it's tied to an older system-wide DPI setting, there's a newer call SetProcessDpiAwarenessContext() which is required for per-monitor DPI awareness, but that doesn't exist for Windows 7. I should be able to just fall back to the old one if the new one doesn't exist though, but I can only test it on my work computer because I use a single-monitor Windows 7 PC at home, so it's a bit annoying to test.

I have absolutely no idea how DPI scaling works on Linux though. What happens if you drag a window from a regular monitor to a high-DPI monitor? On Windows the size of the window and UI scaling are supposed to change dynamically depending on which monitor it's on. I also don't know if there's supposed to be some kind of a window event that tells me when the DPI changes or if I should I try to detect it manually based on the window's position. I only have 1 monitor so it's a bit tricky to learn these things.

>>14209
I don't really like that kind of thing for 3 reasons.
1. It reminds me of /agdg/ trying to take credit for Minecraft and Stardew Valley just because the developers posted something there at some point in time. It just comes off as leechy to me because zzzchan can't be credited for this program's existence in any way.
2. What if there's some drama related to this site in the future? Then the program is stuck being associated with the site even though I or everyone hates it now.
3. I'm not here because it's my beloved home that I'm ready to wage wars for or something, I'm here because I have nowhere better to go.

formats.png
[Hide] (20.4KB, 785x127)

pnglogo--povray-3.7--black826--800x600.png
[Hide] (304KB, 800x600)

An unexpected problem appears. I want to add icons for file formats so they're easier to recognize, but there's no recognizeable logo or icon for png, gif, or bmp. What should I do with them?

It's especially bad for PNG because I want to treat it as the canonical file format for this program, but not having an icon makes it look like a worse choice than the others. There's technically a logo of sorts in http://www.libpng.org/pub/png/ but it's really ugly and becomes a mess at small size, and the fact that I've never seen it before tells a lot. Maybe a cleaned up and/or simplified version of that image would work? Or maybe some kind of custom faux-logo would be better.

>>14218
I found one for PNG: https://libpng.sourceforge.io/index.html (bottom of page)
There doesn't seem to be one for gif, how about making one with an animated word "gif" to make it easy to recognize?
As for bmp, same but I don't have a good idea.

png2.png
[Hide] (237.7KB, 785x785)

icons.png
[Hide] (88.9KB, 958x1066)

file.png
[Hide] (2.6KB, 100x111)

>>14222
I feel like that official png logo/banner/button thing would be worse than nothing at doing it's job. It may be better to take just the image and edit something semi-recognizeable out of it, like pic related. I may have even seen something like this somewhere, unless I'm confusing it with the FLAC logo.

>animated word "gif"
Adding support for animated icons (and making them) just for that doesn't seem worth the effort. All the new image formats and technically png support animations too, so it would be misleading to represent gif as the only animated format. Some Windows 95 -style icon with dithering could work since gif is limited to 256 colors.

BMP feels almost like a plain-data format, maybe some kind of generic file icon would work for it.

Completely unrelated, but I just found out that last year APNG was officially added to the PNG specification (or they're going to), so it's no longer just an unofficial extension.
https://github.com/w3c/png/blob/d5b059ad7f81e789b7689f1c0479db8d1cb41fb8/Third_Edition_Explainer.md

Movie_frame_(cubes)-0.png
[Hide] (562B, 32x32)

Painting-0.png
[Hide] (559B, 32x32)

Sheet_with_cubes_2-0.png
[Hide] (581B, 32x32)

Writing_on_list_with_figures.png
[Hide] (563B, 32x32)

Drawing_figures-0.png
[Hide] (619B, 32x32)

Maybe something like this would work for the .gif icon.
Got from here: https://archive.org/details/windows-95-all-icons

gimp++.png
[Hide] (27.1KB, 340x340)

XP_format_icons.PNG
[Hide] (10.8KB, 133x286)

>>14217
>vector images look kinda shitty when they're tiny
This is kind of a known problem, and the solution is creating a separate tiny version (or several) of each icon. See the GIMP pic.
>I don't want to use SDL on Windows because I'm familiar enough with the Windows API
I did some tests and it seems SDL2 can't into DPI awareness anyway (at least not yet) so here's a Windows-specific solution that does not require you to change your code:
https://stackoverflow.com/a/63987034
1. Create a manifest file.
2. Create a resource file that includes the manifest file name.
3. Compile the resource file using windres and link the resulting object into your executable.
>I have absolutely no idea how DPI scaling works on Linux though.
It doesn't

>>14218
>icons for file formats
Go the Windows XP route and make up your own icons that don't need text to be clear. Pic related.

ef4282c0d1e9e0530964c1a9bf2a8ccef72ff39e1d18d3b2debc6399da59d207.jpg
[Hide] (396.4KB, 900x1119)

Is this dead?

1724497769526893.gif
[Hide] (477KB, 600x338)

>>14681
Yes, and also no.
1. When I started setting up file importers/exporters, I realized that using libraries is way more fucking annoying than I remembered it being. I thought I'd just have to include some library header files and maybe fiddle with some compiler settings and then just learn how to use the library, but actually I need to start downloading build tools and subscribe to their way of building it. I am autistic and invented my own building methods so I had forgotten all about that. I did make the file exporter/plugin system itself by using stb_image as a placeholder though.
2. I tried loading a 51000x74000 image which I've struggled to use in other programs before, and I can't even get that open. I have a downscaled 26000x37000 version but that doesn't load either. This could be a limitation of stb_image, and I realized much later that I may be using 32-bit ints in some memory allocation functions and that may cause a problem.
3. I was fine with the mediocre rendering performance ( >>14161 ) and was thinking I can optimize stuff later, but when I got some version of that large image open, the rendering performance was even worse, even when I viewed it at 1:1 scale. The program doesn't even access the pixels that are off-screen so I don't know why they would affect the performance so much. It's smooth on a release build but I remember noticing the difference immediately when I first opened that image. I could try to split the image into smaller chunks to improve data locality or something, but that's just throwing darts into the darkness.

I also had to start refactoring some of the UI code to support popups and dynamic elements (so exporters can add their own export buttons), which was tedious by itself, but in the process I also ran into bugs in the UI system. None of this is deal breaker but all of them happening back-to-back just took the wind out of my sails.

>>14714
I think you're aiming too high from the get go instead of creating a minimal viable product and iterating on that. Write a paint program that does the bare minimum, and make the code as modular as possible so you can rewrite/remove parts of the program at any time.
>using libraries is way more fucking annoying than I remembered it being
Many libraries have a complex build system that really boils down to "compile these C files together while #defining some macros". If you have the time and patience, track the build commands of each library and then do them "manually" as part of your own build process.
>I may be using 32-bit ints in some memory allocation functions
Always use size_t for these operations and perform sanity checks before allocating to detect overflow/underflow. Also enable ubsan in your compiler.
>I don't know why they would affect the performance so much
If you're comfortable sharing your code maybe anons can take a look at it.
>so exporters can add their own export buttons
This may be a bit too ambitious. I would suggest letting go of the whole importers/exporters paradigm (at least for now) and just compiling support for the different image formats right into your program. If your code is modular enough you can patch importers/exporters back in with minimal changes.

int.png
[Hide] (11.6KB, 760x107)

>>14745
>I think you're aiming too high from the get go
I may have unrealistic expectations for the rendering performance, but otherwise there's no problem.

The importers and exporters are already done and work, there's nothing complicated about those. The only thing that doesn't work are the third party file decoder libraries that I would need in any case. Speaking of libraries, stb_image is using a regular int for it's buffer size variable, which limits the buffer to ~2 GB. A 25000x25000 RGBA image requires 2.5 GB of memory when uncompressed.
>If you have the time and patience, track the build commands
I really don't. I'll almost certainly release the program with the current placeholder decoders and let someone else do proper ones later. Tinkering with some meta build processes makes me want to kill myself and every other programmer on this planet.

>Always use size_t for these operations
It's not that simple. I cannot calculate a data offset if a size or position is stored as 2 32-bit ints ((y*stride+x)*4). In practice I would have to change almost all position/size/offset related variables and loop iterators in the program into 64-bit integers. It's not hard though, I've just never run into limits with 32-bit ints before.

>If you're comfortable sharing your code maybe anons can take a look at it.
There's not really anything to look at. The image data is stored linearly row by row, and the rendering loop pastes the visible pixels onto the window:
Bounds2i b = bounds2i_get_overlapping_area(canvas_bounds_on_screen, window_update_region);
for (i64 y=0; y<b.h; y++) {
	for (i64 x=0; x<b.w; x++) {
		i64 bx = b.x+x;
		i64 by = b.y+y;
		Rgba8* src = image_get_pixel(&canvas->image, bx-canvas_bounds_on_screen.x, by-canvas_bounds_on_screen.y);
		Rgba8* dst = image_get_pixel(&window->image, bx, by);
		*dst = *src; // Replace this with a blending function if canvas has transparency.
	}
}
static inline Rgba8* image_get_pixel (Image* img, i64 x, i64 y) {
	return img->data + (y*img->size.w + x)*sizeof(u32);
}
There's things you could do to optimize this of course, but I don't understand why the image size would have any effect on performance. It makes me think that I misinterpreted something somehow, maybe I was accidentally comparing a release build to a dev build, but I'm too out of the loop at the moment to do tests.

Untitled.png
[Hide] (41.2KB, 1054x764)

I got a bit of extra motivation to work on this.
- Implemented eraser and air brush, and added settings to the current tools.
- Tools show a preview under the cursor.
- Added a toggle for "alpha replacement" mode, if it's on then drawing with transparent color will replace canvas pixels with the selected color. If it's off then transparent colors will get blended to the canvas as you'd expect.
- Added handles around the canvas so you can resize it. The side handles will move so that they remain on-screen as long as the canvas edge is on-screen, unlike in MS Paint where you need to scroll to the middle to use it. Also obviously there's handles on every side, not just right and bottom.
- Added some information and zoom controls to the top of the window.
- Optimized screen updates. The top bar needs to update non-stop because it now shows the cursor position, previously the program would create a "dirty rect" that contains the top bar and anything else that needs to animate (such as the tool preview on top of canvas). Now there can be multiple update regions which significantly improves performance for things like this, it can just render 2 small regions instead of a huge region that contains both. This could still be optimized to be smarter.
- Added a popup menu where you can import/export files, a list of recent files, and a warning that tells you if the current canvas has been changed since last modification.
- Added a config file that can be used to change various things.
- There was a file that stored the current window position and size so they can be restored next time, but now it saves basically everything, like current tool settings and active colors.
- Bunch of other things that I don't remember.

The biggest things missing before I would consider the program usable and ready for some form of release are selection tools and undo. Text tool is important but I don't consider it a critical feature.

I'm concerned that I don't know how undo is supposed to work. For example if you move a very large selection, you would need like 300+ MB memory for a single undo state. Using some algorthms to compress the data would cause lag, as if processing/separating all those pixels wouldn't be a problem as-is. Maybe I'm overthinking again and that's just how it's done.

>>15493
Good progress, I'm happy this project is still going. 
>undo
You can just store the entire canvas and call it a day. The original paint only had 3 undo states anyway.

>>15493
Don't listen to the lazy pajeet (>15495), "b-but muh original paint only had [crippling limitation] anyway" is not how a rational White thinks.
Start by reading this: https://stackoverflow.com/questions/21969746/how-to-efficiently-implement-undo-history-for-images

>>15497
That page doesn't contain any useful information, it just says some obvious crap like some functions like canvas rotation being reversible.

paint.png
[Hide] (46.5KB, 1086x809)

sel.png
[Hide] (8.2KB, 608x539)

krita_selections.png
[Hide] (11.2KB, 1297x513)

I made Windows 7's MS-Paint color theme, it looks surprisingly nice. Also a drop shadow under canvas, the drop shadow renderer is a horrible abomination and probably breaks depending on what parameters you give it, but the result looks good.

I'm trying to think about how to implement pixel-perfect selections, specifically the problem is how to decide which pixels are in the selection. There's 2 parts to a selection, storing the "line", and rasterizing the selected area. Here's the rules:
- All the pixels that your mouse touches must be included in the selection.
- The preview must perfectly show which pixels you're selecting, no weird diagonal lines.
- If you make a loop, the inside must be selected. The first example in pic related is why, usually when you connect a loop, you end up accidentally creating a hole at the connection point. From my experience there's no situation where you intentionally try to create a hole like that, you'll instead substract holes with additional selections.

3rd pic is Krita's shitty selections, the perfect example of what I do not want.

I think it may be possible to create perfect selections just by using a 1px brush and storing each pixel and where they went or came from, but I'm imagining too many weird edge cases. For example what if your selection goes up/down/left/right randomly several times in a 2x2 pixel area, how do you solve it when there's multiple "lines" in the same pixel? The pixel needs to be selected obviously, but the rasterizer would probably be implemented by going from left to right while keeping a counter of how many lines it has crossed and which direction those lines went.

pengui.png
[Hide] (174.3KB, 767x452)

>>15493
>I'm concerned that I don't know how undo is supposed to work.
Instead of storing a copy of the whole image for each action, how about something like:
>Load your image to memory
>Duplicate it and use the new copy as the base of your undo queue
>On each change to the image, store the changed data, their position and extent as an entry to the queue
>Then to undo, apply all the changes from the queue image base to the requested queue position
>If the queue is full, apply the firstmost change to the queue's base image
Think of these as instructions.
You can also extend this to other actions like selections.

For example, a queue in memory may look like this:
const QueueInstruction instructions[] = {
  {
    // Writes a 1000x1000 image with some format to the canvas
    .type = FullRegion,
    .extent = { .x = 1000, .y = 1000 },
    .format = ...,
    .data = ...,
  },
  {
    // Writes a 100x200 region to the canvas at position 400x500
    .type = PartialRegion,
    .offset = { .x = 400, .y = 500 }, 
    .extent = { .width  = 100, .height = 200 },
    .data = ...,
  },
  {
    // Writes another 24x47 the canvas at position 900x730
    .type = PartialRegion,
    .offset = { .x = 900, .y = 730 }, 
    .extent = { .width  = 24, .height = 47 },
    .data = ...,
  },
  {
    // Selects a 99x22 (rectangular) region at position 239x444
    .type = Selection,
    .offset = { .x = 239, .y = 444 }, 
    .extent = { .width  = 99, .height = 22 },
  },
};

2025-03-08_recording_1_compressed5.webm
[Hide] (568.4KB, 1270x850, 00:17)

I guess MS Paint just does the obvious dumb thing for undo. A canvas of this size is 75 MB (no alpha channel) and the memory usage jumps about that much every time I draw a line across the canvas, except on the first line it uses double for some reason. It's easy to be better than MS Paint if this is how it works, so I was indeed overthinking when I though you'd need some kind of smart solution.

That said, I can't figure out what the logic in Krita is. The first line does something similar as MS Paint, but if I draw another line over the previous, the memory usage won't increase at all. If I draw a line in the other diagonal, it increases a bit. Sometimes it doesn't increase at all, but then it jumps at random. I guess it just has some policy for pre-allocating data so it can't be analyzed through memory usage, but it's definitely way more optimized than MS Paint.

>>15504
In Krita, canvases consist of the smallest rectangular area that fits all the non-transparent pixels.

>>15505
I didn't think of that, that would maybe explain why memory usage jumps at first.

The undo system must be implemented in a very efficient way, even if I paint bucket the entire layer (with some lines all around it so the undo can't just say "replace the entire thing with X"), memory is effectively unaffected.

The most obvious optimization I can think of would be to split the canvas into smaller chunks, so you only have to store a small rectangle inside each chunk that was touched by a modified pixel. That would shrink the size of diagonal lines by a lot. Any solid color rectangle could be further optimized into "replace the entire thing with X". You could also use some super fast compressor like Snappy, which could reduce a lot of things into nothingness.

undo.webm
[Hide] (660.7KB, 1050x680, 00:21)

Undo works. For now it doesn't use any kind of optimization.

krita_btfo.webm
[Hide] (622.4KB, 1380x810, 00:14)

clipboard.png
[Hide] (6.1KB, 433x184)

I just realized this program has a better support for transparency than Krita does. It's a simple thing but it feels good.

That said, there's something weird about the image, it's not the same image that I copied, it looks almost like it's jpg compressed. What's even weirder is that Gimp manages to get the correct image with proper transparency somehow. Pic related are the clipboard formats when I copy from Firefox, I assume DIBV5 (BITMAPV5HEADER) is what I'm reading, I don't know why it looks wrong and where Gimp is getting the correct image from. I don't know how to read BITMAP, but that's my best guess.

>>15566
No wait it doesn't look compressed, I don't know what I was smoking. It's just the transparency that's off, there's a dark halo around the image even though there shouldn't be.

>>15567
>dark halo around the image
Might have something to do with straight vs pre-multiplied alpha:
https://learn.microsoft.com/en-us/windows/apps/develop/win2d/premultiplied-alpha
https://shawnhargreaves.com/blog/premultiplied-alpha.html

>>15576
Great guess. The edge is supposed to be pure white with fading opacity, but the edge I'm getting also has the color fading into black along with the opacity. That means that either stb_image is retarded and premultiplies the image without telling me, or firefox is adding a premultiplied image into the clipboard instead of the image that was on the page.

Ok now I'm confused. If I dump the clipboard data into a .bmp file, I get an image with seemingly no transparency at all, just a black background. Even gimp will act like the background is black. However if I open it in my own program, the background is transparent with the dark halo.

So the image HAS an alpha channel, but even Gimp is ignoring the alpha channel this time.

If I drag and drop the file into my program, I'm being given a path to a temporary .bmp file which seems to be identical to the the clipboard data.

Anyway the problem does seem to be with the image that Firefox is giving me, not with stb_image. But that raises the question again: where does Gimp get the correct image? There's a clue though, if I copy paste the image into Gimp and read the semi-transparent pixel values, they're not pure white as they should be. So it seems that Gimp may be imperfectly unpremultiplying the alpha, resulting in an image that looks correct but is not quite correct.

Looks cool Anon.
As someone who has spent over 9000 hours in MSPaint, a few features would be appreciated

1. Being able to alter transparency in a selection (e.g. when pasting something into the picture, make a color of the selection transparent without affecting the underlying image) like a temporary layer until the selection is "done"

2. Font outline capability in a different color to outline the font for contrast.

3. per-pixel selection sizing with modifier+arrow keys (say shift+arrow key) to resize the selection area (could also use a different modifier to transform/scale the selection)

>>15587
>alter transparency in a selection
You mean like using the color picker on the hovering image to make that color transparent? Something akin to that could be possible. Or did you have something more in mind?

I can think of very complicated features for honing the transparency on a hovering image, but at some point it's just not worth adding that complexity since the program starts instantly so you can open a second window and use that to remove unwanted pixels without having to be careful about committing the image to the canvas.

>Font outline
That depends entirely on the capabilities of Freetype. I have no idea how to turn font glyphs into pixels, so I wouldn't be able to create an outline for them either. I'll put it on the todo list to investigate.

>selection sizing with modifier+arrow
There's way too many things you may want to do. For example the right arrow key could:
- move the selection mask to the right (pixels don't move)
- duplicate the selection mask and combine them
- pad the selection mask to the right (1x2 pixel selection would become 2x2, then 3x2, then 4x2...)
- resize the selection mask from the right edge (increase size)
- resize the selection mask from the left edge (decrease size)
- all 5 above options, except the pixels under the selection move too, not just the mask

Other than moving and duplicating the pixels (both of which you can do in MS Paint), I don't feel like any of the above is common enough to deserve a hotkey over the others nor is valuable enough that you'd remember what the hotkey was. What kind of situations do you need them in? Note that this program lets you add to the current selection by holding Shift, and remove from it by holding Ctrl, so you can also tweak the selection that way. The selection also remains even if you change tools, so you can zoom the canvas freely without removing the selection.

It might be possible to add a "selection edit mode" where all operations like brush and resizing affects the selection mask instead of canvas pixels, but I'll have to think if it's worth the complexity it would require.

>>15590
>using the color picker on the hovering image to make that color transparent? 
Exactly

>>15590
Ideally you'd do the steps on at a time, resize the selection mask, then once it's "selected" use the arrow keys for a transform of the selection, or if you had a modifier key to do one or the other at any time.
It's mostly an issue of selection, scaling and moving accuracy vs the mouse

precise_transform.png
[Hide] (8KB, 501x491)

>>15598
Holding Ctrl to move/transform the selection mask without the pixels should be doable.

One idea that could be considered is the concept of "selecting" one of the handles on a selection (by right clicking or using hotkeys like C+ArrowKey). If no handle is selected, then arrow keys will move the entire selection as usual, but if one of the side handles are selected, then arrow keys will move that handle. Exactly how it works when clicking and dragging with a mouse.

I'm having second thoughts about this entire program. There's all kinds of neat little things I want to add, but the way the UI is set up is incompatible with most of it. The settings bar on top is already cramped and requires more room than I'd like it to, and I haven't even implemented all the originally planned tools and settings yet.

For example, one thing I want is the ability to copypaste whole RGB values, for example "255,140,20", not just individual channels. But where am I supposed to fit that input?
Another thing I realized is that there's a lot of selection settings, they are shared across all selection tools, and they're also mostly used by the canvas itself. It might be better to put selection/transform settings into a separate panel, especially since magic wand requires it's own settings that already take space. But where is that panel supposed to be?
I also want to be able to mark/name regions and export them as spritesheet information.

Maybe I can just use floating panels, but I feel like they're a bandaid to a bigger issue. Before this program, I had an idea for a bigger graphics editor with a much more powerful UI design (similar to Photoshop's attachable panels), and I feel like I should just switch to that. But if I do that, I'll probably also feel like doing a bunch of other things that compromise on the simpleness of this program.

>>15601
When a tool is selected, have it replace the tool selection area with tool detail area? Re-use the space.