Scrolling/panning doesn't / can't work about openoutpaint HOT 47 CLOSED

Well, knew that would come to bite us sometime!

We actually changed that because due to incompatibility between browsers, sometimes scroll would simply not do anything because of too tiny deltaY values.

I guess we will have to implement this properly now.

Will search for the commit regarding the mouse changes and update here.

During the next few days it will be a bit hard for me to implement these due to the holidays. The drag modifier specially will require quite some structural change to the input lib. The scroll fix should be a bit easier.

from openoutpaint.

That's a good point. Notebook users would have some difficulties with a track pad. We can probably allow panning with the right mouse button as well. Would that help in your case?

Left dragging could also probably be implemented now that I think about it (using the Ctrl modifier key)

from openoutpaint.

Sadly, no. Macbooks only have one "button". I can right-click by clicking with two fingers, but I can't right-click-and-drag.

The mac-native way to do that is to hold the Option modifier key, which is roughly equivalent to Alt.

from openoutpaint.

Will see what I can do... I don't think it would be too hard, but it would definitely not be easy from how we handle mouse inputs.

from openoutpaint.

This is more of an enhancement request than a bug per se.

from openoutpaint.

While I'm here... the UI seems to react to scroll events, without considering the size of those events. Touchpad scrolling has much higher granularity than mouse scrolling.

In particular, the smallest possible finger movement leads to scrolling all the way from 512x512 to 2048x2048 and then back through 512x512 at least once. 🤣

What I think you'd need to do is look at WheelEvent.deltaY, as well as deltaMode, accumulate deltas and only treat the event as 'real' once it's scrolled enough to match one mouse-wheel movement. ...or preferably more than one. The touch pad is harder to control.

from openoutpaint.

This is the previously referred commit in which mouse wheel handling was changed: aee812b

A new commit (3d29847) has been pushed to the testing branch with an attempt to fix smooth scrolling devices on chrome. In chrome, smooth scrolling devices send A LOT of events, differently from Firefox, which accumulates smooth scrolling data until a threshold of a line is reached, and sends a single event.

@Baughn if you could give this fix a look to see if it fixes your touchpad scrolling issues (You would need to clone this repo and run git checkout testing to check).

@zero01101 Would it be possible to create a new deployment in github-sites for the testing branch? (something like https://zero01101.github.io/openOutpaint-testing/)

from openoutpaint.

Values are based on my tests:

Snapping Mouse Wheel on Firefox:

Snapping Mouse wheel on Chrome:

Smooth Touchpad on Firefox (Admittedly, would not be smooth):

Smooth Touchpad on Chrome:

from openoutpaint.

Would it be possible to create a new deployment in github-sites for the testing branch? (something like https://zero01101.github.io/openOutpaint-testing/)

hmm, apparently not without just dumping the testing branch in an entirely different repo (https://github.com/orgs/community/discussions/21582, https://stackoverflow.com/questions/32629223/github-pages-dev-branch) but can offer this in penance as a hacky workaround:
https://raw.githack.com/zero01101/openOutpaint/testing/index.html

from openoutpaint.

"Buy a macbook" is an unfortunate debugging instruction

but it's hilarious and luckily(?) i have a macbook provided by my employer, i just never use it for anything stable diffusion related... i can "confirm" that you CAN INDEED zoom by holding cmd and using the two finger gesture on the trackpad on a 2021 m1 macbook pro running a pretty outdated macOS, but god yeah it's an awful experience isn't it

i could respond to "Buy a macbook" with "buy a real mouse" but that seems petty ;)

from openoutpaint.

Not everyone have a middle button. I'm voting for just a RMB for panning.

By @w84death on zero01101/openOutpaint-webUI-extension#9.

For now,

We can't really simply RMB as quick RMB drags would also be counted as clicks, which would just erase whatever is under them on some tools.

I'm considering (Alt/option) + LMB Drag as an alternative for panning, which could be a reasonable compromise for both Macbook/non-middle click users. Ctrl + LMB Drag could also be an alternative, as it would remain in the realm of "Ctrl is the camera button" thing.

from openoutpaint.

yeah, i'm personally more inclined to go with left-click over right-click myself for this as well; i definitely prefer ctrl over alt just to stick with the "camera modifier key" paradigm just as a gut feeling :)

from openoutpaint.

Hi, me again. I have a macbook, but I use an external usb mouse and keyboard. Pan or zoom isn't working for me. MacOS, using chrome. I have a windows desktop, would you want me to try it?

from openoutpaint.

So, Ctrl + mouse wheel is not doing anything?

from openoutpaint.

should probably be cmd+scrollwheel on mac i believe...

from openoutpaint.

....PEBCAK, ctrl is doing it. false alarm.

from openoutpaint.

oh, it is ctrl on mac? huh, will have to update docs

from openoutpaint.

He is using an external keyboard. Not sure if an apple one.

from openoutpaint.

K, so it's not my fault at least, the docs did say command.

from openoutpaint.

It is an apple keyboard.

from openoutpaint.

Okay, so Ctrl it is!

from openoutpaint.

lmao i coulda SWORN it was cmd on my macbook, i'll have to check that

from openoutpaint.

I can confirm that zooming work now (using ctrl, not cmd), and brush size / render size selection feels comfortable. Panning doesn't work, but I don't think it was expected to.

Zoom would probably feel more comfortable if it was centered on wherever the cursor is at the moment, instead of always centering on the center of the canvas. (And, I'll admit, that would also work as a semi-functional replacement for panning.)

from openoutpaint.

Hi, @Baughn! Could you test our solutions (allowing LMB drag using control, and mouse wheel fix) on the testing branch? (git checkout testing on the openOutpaint directory, or app directory without webui restart, if using the extension)

from openoutpaint.

It is now on main, actually. Just update openOutpaint and test the changes.

from openoutpaint.

Right... let's see.

• Zooming in/out now zooms in/out on where the cursor is, which is great!
• Unfortunately, it does so whether or not I'm holding ctrl. 🤣
• I don't think this is new, but if I turn on 'sync cursor size' then the scroll wheel alters the stable diffusion resolution setting, but not the cursor size. It also does so at super high speed; the new scroll logic doesn't seem to apply.
• After I turn it back off, the cursor size remains fixed; the scroll wheel now only zooms.

If you got an email with another comment earlier, there was some confusion due to not hard-refreshing my browser. I've deleted that one.

• Actually, after performaing an action (?; dreaming, at least), the scroll wheel now affects cursor size again.

from openoutpaint.

Are mouse controls still working properly?

from openoutpaint.

Which ones? (I thought I covered everything.)

Oh, right, LMB drag. That does work.

from openoutpaint.

Oh no, general mouse controls! Just to see if I didn't break anything!

from openoutpaint.

Those seem to work.

from openoutpaint.

Trying it again today, the zoom-always-happens issue appears to have disappeared. I haven't updated the extension in the meantime, so I can only blame the browser cache... it might be a good idea to put a version number (hash?) in the filenames, if they don't have that already.

from openoutpaint.

it might be a good idea to put a version number (hash?) in the filenames, if they don't have that already.

Agreed, as some errors seem to be derived from caching on other issues as well. Have been thinking on how to do it in a way that is sort of seamless for developers though. Git hooks are the most obvious solution, but we cannot really verify if a developer actually set up the hooks correctly.

GitHub actions alone would be fine, but would pollute the commit history quite a lot (one extra commit for each push to branch/pull request).

An approach that combines both, and only creates a correction commit when run on GitHub actions with incorrect hashes would be optimal.

from openoutpaint.

It doesn't necessarily have to be part of the filenames, if you're using static file serving.

"foo.js?42" is a distinct resource from "foo.js?43", and won't be read from cache. So it should work if you put the current git hash in the query fragment, say.

from openoutpaint.

Still, it would be pretty gruesome to have to update values for every resource indexed! Have sent a pull with some scripts, hooks and GitHub action entries at #130! Will hopefully not be a problem anymore going forward.

from openoutpaint.

You can now give a look at testing; should fix some sync issues.

from openoutpaint.

Well, my implication was you'd generate the URLs on the fly. Possibly by scraping the hash from git, as in--

...er, I still haven't gotten used to that ability. ^^;

That way you wouldn't need to update anything manually. That said, the conversation has gone wildly off-topic for this bug... and I might just send you a PR instead. Is there an IRC channel or Discord server I should be in?

from openoutpaint.

Not really, actually. We could ask @zero01101 to create one!

Also, we can't really generate anything on the fly because this is a fully frontend-only application with static file serving, and we plan to keep it this way. :)

Using timestamps is also non-optimal, as it would basically never cache.

So this is the most we can do to perform some type of proper cache busting. Still, I think this is a good compromise on developer ease and reliability.

from openoutpaint.

lol ok so i uh... have used discord about 4 times before? i'm clearly old; every time i log in i think "man this should've just been a forum or something" lmao

i've got a local homelab IRC server idiotically exposed to the internet at irc dot djabacus dot net on port 6667 (annoying url to deter bot scraping like that'll do anything at all) and just started an #openOutpaint channel, but if all the cool kids truly prefer discord i guess i can probably look into what that entails ;)

from openoutpaint.

from openoutpaint.

¯\_(ツ)_/¯

https://discord.gg/tCPTr3pu

from openoutpaint.

Hi, @Baughn! Just to confirm if there is anything else that should be fixed!

from openoutpaint.

Just one bug left, though it's an odd one.

If I click 'sync cursor size', whether to disable or enable, then the scroll wheel stops working to change cursor size until I ctrl-drag to move the canvas. Zooming the canvas works, but does not unstick it.

from openoutpaint.

When you do this, is the reticle of the dream tool blueish? If so, it's more that the checkbox is focused, so clicking anywhere, including the canvas, should restore cursor size wheel handling.

For the future, I guess that we can automatically blur focus on checkboxes on value change event...

from openoutpaint.

It doesn't visibly change appearance, but yes, that seems to be the cause.

from openoutpaint.

From what I can test here, clicking on a checkbox does indeed make the reticle/crosshair turn bluish in appearance. Still, here is a fix for the full checkbox issue:

from openoutpaint.

zero01101/openOutpaint-webUI-extension#11 (comment)

Did your testing branch break the main branch?

from openoutpaint.

Will be closing this issue for now, as all pending problems seem to be resolved.

from openoutpaint.