Double clicking on token

[SilentRuin]

Double-clicking on map to get a token to show its sheet has become even harder now (LOS lighting map). As I pointed out the map is interpreting every part of a double click on a token as a click and processing the select and vision off an on every time and no sheet will come up (used to be if you did it enough it would - now its even worse).

I'm doing this in 5E but I assume this is true in any ruleset that supports token double clicking to do something.

[SilentRuin]

You can see this even when it works in a simple map. The token will select and deselect when you double click. Simple maps won't interfere with the sheet coming up as they are not doing as much on that select and deselect (which should not be happening anyway on a double click). Complex busy maps though - that select deselect will be noticeably slower and the sheet will not come up (whether this is because the double click thinks its two single clicks due to select/unselect token processing delays or is lost is irrelevant as the selects should not be occurring as they are single click functionality).

[SilentRuin]

My only work around - zoom into token so it has nothing to process in vision for map - then of course the delay is minimal and the sheet will come up on the double click...

https://www.fantasygrounds.com/forums/attachment.php?attachmentid=59476&stc=1&d=1702495431

[Mike Serfass]

I'm using Savage Worlds (SWADE) where double-clicking a character token on a map opens the character sheet.
I see the click happens twice, as SilentRuin describes. The character sheet opens as expected, but it is selecting then deselecting the token.
Double clicking in the CT selects then deselects the character token in rapid succession as well. The expected behavior of the map opening and centering on the token still happens.

[Moon Wizard]

I'm sort of confused by why this is suddenly an issue associated with the new release. I went back through all the builds from July 2023 until now (v4.4.3 through v4.4.8); and the click behaviors appear to be the same for all those versions. So, it appears that this has been the standard behavior for quite a while.

Double clicking on a token produces the following events:
* Click Down
* Click Release
* Double Click
* Click Release
This includes toggling the selection of the token as part of the standard UI behaviors.

Regards,
JPG

[SilentRuin]

I'm sort of confused by why this is suddenly an issue associated with the new release. I went back through all the builds from July 2023 until now (v4.4.3 through v4.4.8); and the click behaviors appear to be the same for all those versions. So, it appears that this has been the standard behavior for quite a while.

Double clicking on a token produces the following events:
* Click Down
* Click Release
* Double Click
* Click Release
This includes toggling the selection of the token as part of the standard UI behaviors.

Regards,
JPG

I've complained about this off and on for a year and been ignored. And now that all the new lighting changes have accumulated to make the delay even more noticeable you wonder why the bug is suddenly a problem?

Double click - is not - Single click. This is known.

Let's skip the five stages of denial and just get to the acceptance part and fix it.

[Mike Serfass]

Maybe it wasn't noticed before graphics / los and lighting changed?

[Moon Wizard]

Ok, I just want to be clear, because I like one line summaries of issues to make sure we're all on the same page.

My current understanding is:
There is now additional delay when a click is registered on a token (which does select/unselect, updates vision, etc.) which prevents the double click event from triggering (due to the time delay preventing the event from registering during the double click time frame).

Is that correct?

Thanks,
JPG

[SilentRuin]

Ok, I just want to be clear, because I like one line summaries of issues to make sure we're all on the same page.

My current understanding is:
There is now additional delay when a click is registered on a token (which does select/unselect, updates vision, etc.) which prevents the double click event from triggering (due to the time delay preventing the event from registering during the double click time frame).

Is that correct?

Thanks,
JPG

Yes.

Typically code that processes a single click calls functionality to insure its not a double click so that it does not treat a double click as a single click - because its not.

[Mike Serfass]

It hasn't prevented the double click event for me, but that could be because the maps I tried this on aren't too large or heavy on los and lighting.
I can see the double click being blocked if I had a large map or lots of los and lighting. A long refresh might block the double click event.
The single click event is firing in addition to the double click, and it seems to fire before the double click event is handled, then again after the double click event.
Should I try on a more complex map?
Would a video help?

[Moon Wizard]

@SilentRuin, thanks for confirming; I'll circle with @pindercarl to discuss.

@MikeSerfass,
Based on what @SilentRuin confirmed, the issue he reported would only occur on complex maps where the calculation times exceed the double click window.
I used an extension to test the click behaviors as noted above. The standard event behavior for "double click user action" has been as follows for the last year or more. (Click Down, Click Release, Double Click, Click Release). I can provide the extension I used to test across multiple versions.

Regards,
JPG

[Moon Wizard]

I circled with @pindercarl, but he does not have a quick answer. We're looking at possibly introducing more multi-threading to handle some of the image-based calculations, but this can introduce lots of other issues with timing, lagging displays, synching, and more. It's something we'd have to build just to investigate whether it would work. This is not something that can be addressed quickly, and our focus is primarily on building out the new image features that Doug showcased which required changes that apparently introduced additional lag in your scenario. Also, it's not a commonly reported issue, which implies that the complexity of your scenario is much higher than most (but we already know that).

For now, you'll have to look at reducing the overall complexity of the scenario until we have time to look at it. I've made some suggestions below; you might find that some adjustments have more effect than others.

Some ideas of things to consider:
* Reduce image size on screen (# pixels being updated directly correlates to overhead) (i.e. use lower screen resolution, use floating window instead of background panel, make floating window smaller, ...).
* Reduce number of tokens on map (# tokens has a multiplicative effect on calculations, not linear) (i.e. use less tokens, don't pre-place unseen encounters, ...)
* Remove special FX layers (special FX layers, especially blur and multiple layers, can impact performance) (i.e. don't use blur, reduce FX, remove FX, ...)

Regards,
JPG

[SilentRuin]

I circled with @pindercarl, but he does not have a quick answer. We're looking at possibly introducing more multi-threading to handle some of the image-based calculations, but this can introduce lots of other issues with timing, lagging displays, synching, and more. It's something we'd have to build just to investigate whether it would work. This is not something that can be addressed quickly, and our focus is primarily on building out the new image features that Doug showcased which required changes that apparently introduced additional lag in your scenario. Also, it's not a commonly reported issue, which implies that the complexity of your scenario is much higher than most (but we already know that).

For now, you'll have to look at reducing the overall complexity of the scenario until we have time to look at it. I've made some suggestions below; you might find that some adjustments have more effect than others.

Some ideas of things to consider:
* Reduce image size on screen (# pixels being updated directly correlates to overhead) (i.e. use lower screen resolution, use floating window instead of background panel, make floating window smaller, ...).
* Reduce number of tokens on map (# tokens has a multiplicative effect on calculations, not linear) (i.e. use less tokens, don't pre-place unseen encounters, ...)
* Remove special FX layers (special FX layers, especially blur and multiple layers, can impact performance) (i.e. don't use blur, reduce FX, remove FX, ...)

Regards,
JPG

Honestly if you guys aren't going to handle a double click as something that is not processed as a single click then you should do what Natural Selection extension does and have single middle mouse button trigger the double click functionality.

As it is I'll simply use this when I notice the double click not functioning over a token (which is always in my non simple maps).

[Zacchaeus]

Not everyone will have a middle mouse button - especially Mac users. FGU is a multi platform application and so it has to work across all of them.

[SilentRuin]

Not everyone will have a middle mouse button - especially Mac users. FGU is a multi platform application and so it has to work across all of them.

True. But in the face of "no valid solution or workaround", and trust me dumbing down a map as suggested is not a valid solution...

Something... is better than nothing.

At least I suggest workarounds for windows users.

I'm sure something similar could be suggested for Mac users - as for sure double click when not supported as a separate operation from single click - gives undesired results. If FGU insists on processing it as such their only solution is to move the double click functionality to single click with some other button/pressed button to trigger it.