Bug 1240 - NEWT bcm.vc.iv only consume one mouse input event per frame
Summary: NEWT bcm.vc.iv only consume one mouse input event per frame
Status: CONFIRMED
Alias: None
Product: Newt
Classification: JogAmp
Component: embedded (show other bugs)
Version: 2.4.0
Hardware: embedded_arm linux
: --- minor
Assignee: Sven Gothel
URL:
Depends on:
Blocks: 1178
  Show dependency treegraph
 
Reported: 2015-09-30 23:56 CEST by Xerxes Rånby
Modified: 2015-10-05 08:31 CEST (History)
0 users

See Also:
Type: DEFECT
SCM Refs:
Workaround: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Xerxes Rånby 2015-09-30 23:56:06 CEST
http://jogamp.org/log/irc/jogamp_20150930050514.html#l203
(23:06:59) xranby_f22: whats on my mind,, yes,, i ran some tests today of processing 3 using various input devices in combination with the broadcom video core iv driver.     the good parts: the touch screen under x11 in combination with the X11Underlay work superb    i am really happy that it is snappy       the hmm parts:   if you attach a mouse input device that generate a-lot-of events   then the bcm.vc.iv   only consume one mouse input event per frame     causing events to pile up when you move the mouse...   the effect is that the mousecursor move around on the screen slowly while the input queue is consumed one event a frame
(23:07:00) sgothel: similar to our fixed function pipeline emulation
(23:09:29) sgothel: so we need to compare this w/ plain X11 .. and see if it works there well
(23:09:49) sgothel: if so - why is event dispatching slowed down to raspi?
(23:10:04) sgothel: probably b/c we don't follow write-once model?
(23:10:12) xranby_f22: the event dispatching needs to update the bcm mousepointer
(23:10:14) sgothel: i.e. the events itself are copied for example
(23:10:23) xranby_f22: the special dispmanx surface
(23:10:39) sgothel: so maybe, we shall merge both EDT's here
(23:11:13) sgothel: i.e. need a custom EDT dispatch method handling both
(23:11:29) sgothel: should be possible, since we pass a Runnable for this task to the EDT
(23:11:46) sgothel: then: also need to patch the X11 event, so we don't need to copy it
(23:12:07) sgothel: this write method on the otherwise event object shall be mostly private :)
(23:12:28) sgothel: AFAIK: replace the target object X11 Window  -> BCM Window
(23:12:55) sgothel: then we have input handling more fluent
(23:13:18) sgothel: instead of two EDT's periodically updating things .. horrible :)
(23:13:30) sgothel: while exchanging events .. more horrible :)
(23:14:05) sgothel: we touched this issue, at least the 'copy event' thingy a while ago
(23:18:08) xranby_f22: i am always happy to hear that you have a clear view, my mind always gets clogged when it get too much multithreaded
(23:18:44) sgothel: :) .. I have to  put myself in a meditation state of mind to control 'em all :)
Comment 1 Xerxes Rånby 2015-09-30 23:58:53 CEST
This bug would provide a solution to bug 1178 cc5, adding this bug as a blocker for 1178.
cc5: re-use the x11 newt events as is then it would support multiple mousepointers etc
https://jogamp.org/bugzilla/show_bug.cgi?id=1178#c12
Comment 2 Xerxes Rånby 2015-10-01 09:57:41 CEST
Having only one event dispatch thread would makes it easy to solve
1178 cc2: if you move the X11 window outside the visible screen then the overlay gets recentered by bcm.vc.iv code to be inside the screen.
Fix for cc2 require that the bcm.vc.iv driver send a new WindowEvent when it have re-centered inside the screen.
Because having two event dispatch threads one for X11 window toolkit and one for the BCM VC IV dispmanx toolkit easily cause hairy deadlocks.
https://jogamp.org/bugzilla/show_bug.cgi?id=1178#c12
Comment 3 Sven Gothel 2015-10-05 08:31:53 CEST
moved to post 2.3.2 - sorry