Re: Better handling for mouse events in UI frontends

On Sunday, 15 May 2022 02:25:26 PDT Nikita Zlobin via gnuplot-info wrote:
> For now UI's like gtk and qt try to handle all events. This may be
> doable with mouse, but very hard with input devices with extreme events
> rate like touchpad (one time I tested it - it seemed to reach 1000
> events per second). If UI can't do it in time - events accumulate and
> we get UI hung while trying to handle all accumulated movements.

This is not true in general.   At least for mouse movement events,
the program responds only to the most recent one and throws away
any that backed up behind it.   I have not noticed any problems with
mousing on the touchpad of my laptop, but if you have seen problems
on your setup then a bug report giving more detail may be appropriate.

hardware?  OS? Which driver?  gnuplot version?

> Simple panning may be not so problem, because it takes absolute
> event coordinates rather than displacements. 

Do you mean zooming (click-and-drag to make a box)?
The panning operations respond to left/right/up/down events rather
than coordinates.  

Is it possible that you are seeing an issue with the "zoom factor" rather than the event rate?
You might try
	set mouse zoomfactor 0.1, 0.1

> As for others - I see 2 variants:
> - either separate drawing from event handling
> - or skip events, whose handler is busy right now

I think both of these are already true, although it is possible that this
depends on the platform you are using (for example I am not familiar
with wxt on Mac OS via cocoa, or variant back-ends for qt on Windows).

I  suggest you file a bug report and give enough information to reproduce
the problem.

	cheers,
		Ethan


_______________________________________________
gnuplot-info mailing list
[email protected]
Membership management via: https://lists.sourceforge.net/lists/listinfo/gnuplot-info