Scrolling/panning doesn't / can't work

[Baughn]

Describe the bug

"To pan, hold CMD and the scroll wheel, then drag. To zoom, hold CMD and scroll."

My laptop doesn't have a scroll wheel. It's not clear how I would pan; I'm not aware of a way to create middle-click-and-drag events, and most applications use modifier keys instead.

Scrolling is a valid touch gesture, of course, but CMD-scroll also has no effect; the cursor size changes instead.

To Reproduce Steps to reproduce the behavior:

1. Buy a macbook
2. Go to https://zero01101.github.io/openOutpaint/
3. Attempt to zoom

Expected behavior

Functioning zoom.

Desktop (please complete the following information):

• OS: OSX 12.5.1
• Browser: Chrome / Safari
• Version: Current as of 2022-12-23

Additional context

"Buy a macbook" is an unfortunate debugging instruction, and this will probably work if I connect an external mouse... I hope. However, maybe you could add a "pan" tool? I think "click m, click-drag" would be equally fast anyway.

[seijihariki]

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)

[Baughn]

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.

[seijihariki]

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.

[seijihariki]

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

[Baughn]

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.

[seijihariki]

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.

[seijihariki]

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

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/)

[seijihariki]

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:

[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/)

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

[zero01101]

"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 ;)

[seijihariki]

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

By @w84death on https://github.com/zero01101/openOutpaint-webUI-extension/issues/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.

[zero01101]

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 :)

[createperhaps]

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?

[seijihariki]

So, Ctrl + mouse wheel is not doing anything?

[zero01101]

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

[createperhaps]

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

[zero01101]

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

[seijihariki]

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

[createperhaps]

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

[createperhaps]

It is an apple keyboard.

[seijihariki]

Okay, so Ctrl it is!

[zero01101]

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

[Baughn]

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.)

[seijihariki]

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)

[seijihariki]

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

[Baughn]

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.

[seijihariki]

Are mouse controls still working properly?

[Baughn]

Which ones? (I thought I covered everything.)

Oh, right, LMB drag. That does work.

[seijihariki]

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

[Baughn]

Those seem to work.

[Baughn]

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.

[seijihariki]

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.

[Baughn]

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.

[seijihariki]

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.

[seijihariki]

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

[Baughn]

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?

[seijihariki]

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.

[zero01101]

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 ;)

[createperhaps]

Sorry to butt in but discord is super easy. It had private messages but it is sorted by servers which are hosted by discord, and a server is divided into channels. No ports or anything needed

On Thu, Dec 29, 2022 at 6:32 PM tim h @.***> wrote:

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 ;)

— Reply to this email directly, view it on GitHub https://github.com/zero01101/openOutpaint/issues/116#issuecomment-1367637151, or unsubscribe https://github.com/notifications/unsubscribe-auth/A4TQTDCEYHIOOA7QPYNDF7DWPYNSBANCNFSM6AAAAAATH6NWBQ . You are receiving this because you commented.Message ID: @.***>

[zero01101]

¯\_(ツ)_/¯

https://discord.gg/tCPTr3pu

[seijihariki]

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

[Baughn]

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.

[seijihariki]

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...

[Baughn]

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

[seijihariki]

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:

[createperhaps]

https://github.com/zero01101/openOutpaint-webUI-extension/issues/11#issuecomment-1368081205

Did your testing branch break the main branch?

[seijihariki]

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