fuzzyzilla / fuzzpaint Goto Github PK

When two hotkeys share the same key but with differing modifiers, the hotkey with the most modifiers takes precedence. However, the hotkey with high precedence will sometimes continue to be issued when the modifiers are released and the hotkey with low precedence is pressed. This is likely an issue in the winit event collector.

Two bugs have been spotted with the octotablet-egui integration implemented in window.rs and stylus_events.rs (thanks marco~!)

• When "Display Scale" (dpi) is not 100%, the stylus location is scaled incorrectly. With scales above 100%, the interactive region is squished towards the top left. This does not effect stylus interaction with the document, and does not affect the mouse.
• Stylus events are double-counted, presumably windows emulates mouse motion when the stylus moves (unrelated to the emulate_tool_from_mouse option in octotablet which controls the reverse). This causes jagged stroke previews and mis-counted clicks on UI elements.

There's a couple of things that are 50-90% implemented that i stopped and merged because i got worn out/burnt out that I really must revisit and spring-clean. Todo list :3

• Partial state clones - left as a todo!() but never used. Could present a substantial performance boost on large documents (which given the state of things is not likely to be a problem in the app's current form :P)
• File IO - left as a skeleton that saves and loads the bare minimum to prove to myself that it was "working"
• Object pickers - got real bogged down in API design and after completely stagnating I merged it to avoid divergent histories. Never called into.
• Text rendering - similar story as above. Also some ecosystem problems, trying to find a font database, and recently learned that rustybuzz is deprecated D:

This project is huge!! Time to split off components into their own crates, so my work can be more focused on just the core art functionality of Fuzzpaint and so that some of my code can be used by others in the rust ecosystem. Plus, easier to bugfix, cleaner code since I'm not tempted to put pen logic in the UI or whatever, faster compile times...

Ideas for what can be split off, in order of likelihood of me doing so:

• egui renderer - already exists: egui_winit_vulkano which I have been working on optimizing prior to integration. Plus, has more accurate color and better support for new egui features.
• Tablet/Stylus/Pad input - Implemented in octotablet, #36.
• Rebindable hotkeys - I like what I have now so that could be broken off to it's own crate, but I have not looked at what the wider ecosystem has to offer. Currently it is deeply inspired by Godot's Input class.
• Rich text - containers and editors. While UI toolkits provide a way to edit rich text, they don't provide a stable representation/datastructure to store it in.
• Zero-copy RIFF - I am extremely proud of the performance I achieved with my RIFF readers and writers, and I could easily make them a crate. Before I throw my hat into the ring though I need to check the other libraries - no point in posting a worse version of the same thing someone else did better :P
• Gizmos - A very niche UI mechanism that I am highly doubtful exists elsewhere and is maybe of dubious re-usability. In particular, composable, interactive onscreen shapes where the "canvas" and "viewport" are in separate coordinate spaces and can be mixed and matched for different parts of the graphics/transforms. I.e., a resize box, drag handles, on-document markers, etc.
• Command/State trees - Very close to an Operational CRDT which was a term I didn't know of at the time I wrote it. These are deeply baked into the architecture of fuzzpaint and it would require a lot of thought on how/if it can be extracted in a generalized form. I'm also not proud of the state it's in within fuzzpaint (by the time I finished it I was exhausted of that chunk of code and just wanted it to be done lol) so it needs some rethought anyway. It would be positively lovely to have it be however, as it makes multi-user editing, tree-undos, and parallelized editing/rendering a drop-in thing.

Currently, resident memory sits at 100MiB. This is much higher than my goal. Just a few months ago, it sat at a mere 30MiB!

After profiling with dhat, all non-"insignificant" - as determined by dhat - allocations come from egui. The egui project is not currently in a phase of optimization, but perhaps I should help out there!

Wayland has inexplicably started crashing after mousing over the window, caused at some point during the Globals refactor - it is now disabled (it didn't have stylus support anyway, so not much is lost).

Wayland is certainly a high-priority support point! X11 is only the api of choice for now because of how effortless pressure support is thanks to winit's undocumented support of it through AxisEvents lol.

On window managers that allow forcing windows into exclusive fullscreen (sway, hyprland...) the window thread prints an error and the app stops responding. Exiting fullscreen sometimes recovers, sometimes not.

trying to use a swapchain image without depending on a corresponding acquire image future

The change listener thread spins, using ~6% CPU - magnitudes more than the entire rest of the app at idle. This comes from the implementation of the bus::BusReader::*recv* family of functions, which use adaptive spinning to check the state of the bus. Go fix it, future me!!