- When changing from normal E pointer to the system one (as you enter the area of a windos) consume a lot of CPU.
- As a result of the above the movement becomes jerky.
- Even after you close the windows the movement of the pointer remains jerky and you have to restart E to get it to behave properly (ish) even though it still seems to throttle the CPU.
- The system pointer -which now also works on internal stuff like EFM- doesn't change to indicate resize on the internal windows. (move the pointer to a corner or edge of an internal window)
- rE7871d58ce3e9: add separate mouse in/out handlers for internal wins
rEFLf48f565306e9: ecore_drm2: Fix page flipping
rEFL2119a74a5d5e: elm win: only set wl cursors on mouse in to the window area
rEFL95b5533f73c3: elm win: set input regions for wl windows again
rE771f71e6a9db: add separate mouse in/out handlers for internal wins
Weird pointer behavior (in general) started after dh merged the drm2 and made elput default. Also around that point there were other pointer related commits by Jpeg
The use of system pointer on internals started after your last pointer commits (obviously).
Apb: what's the hardware here? if it's intel graphics, what's the kernel version?
I'm seeing some performance issues with the intel dmabuf allocator - it could be causing some (but not likely all) of these problems...
intel atom n270 (i915 i believe, using SW rendering because it doesn't support any modern opengl)
The whole software stack is whatever comes with arch with the exception of EFL and enlightenment being git.
If either of you can test my devs/derekf/nerf_dmabuf enlightenment branch to see if the problem disappears, that'd be hugely helpful.
Some of the issues (black square flashes behind cursor change) are unrelated, but performance will likely improve...
One thing i noticed today.
The pointer changes from the enlightenment one to the system one at about 10-15 pixels outside the window limits. To see what i mean. open a window (Elementary app) and move the pointer from outside to the inside of the window. It will change before it enters the window area.
This behavior only happens with elementary. Qt apps change the border precisely at the border. GTK apps also have a gap but in that case it changes to a resize pointer (and also to the gtk pointer)
Yay to the three different pointers you see on the desktop. Year of linux desktop and that shit :/
The way i reproduce it is:
Open EFM, etui with a pdf, ephoto with a photo and terminology. > Move the windows a bit around and i start moving the pointer on the screen so it changes. After a while it becomes jerky for short periods of time. After i close all the widows the jerky pointer remains.
Needs restart to come back to normal.
CPU usage remains rather high for my liking but it might be due to my HW.
Also the artifact the first time the pointer changes is still there.
That log helped create and close T4123 which resolves point 3 on this list.
There's another performance bug left relating to page flipping and vblank handlers that his hardware somehow manages to hit - this requires new features to fix and can't be done before 1.18
I'm closing this ticket as I believe every item on the list to be resolved