Page MenuHomePhabricator

Pointer issues.
Closed, ResolvedPublic


  1. When changing from normal E pointer to the system one (as you enter the area of a windos) consume a lot of CPU.
  2. As a result of the above the movement becomes jerky.
  3. 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.
  4. 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)
ApB created this task.Jun 6 2016, 4:26 AM
zmike added a comment.Jun 6 2016, 8:12 AM

Do you know when this started?

ApB added a comment.Jun 6 2016, 8:56 AM

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

devilhorns triaged this task as Normal priority.Jun 13 2016, 8:39 AM
zmike raised the priority of this task from Normal to Showstopper Issues.Jun 18 2016, 7:47 AM
zmike added a project: efl.

The pointer locks up sometimes, and its lack of smoothness since the drm2/elput switch makes this a bug of the highest priority.

ApB added a comment.Jun 19 2016, 3:34 AM

While you are at it:
When the pointer changes from E to System it sometimes creates an artifact on the pointer. A black square of some sort.

Here i've the locking issue too. EFL git master, E git on Linux x86-64

zmike added a comment.Jun 20 2016, 8:21 AM

Here i've the locking issue too. EFL git master, E git on Linux x86-64

Is this in X11?

Okay, so then it's likely this is also related to the recent internals refactoring.

jpeg added a comment.Jun 20 2016, 6:52 PM

Any special condition here? Like a theme, an application in particular, ... I can't observe any jerkiness or spike in CPU usage.

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

ApB added a comment.Jun 21 2016, 7:36 AM

intel atom n270 (i915 i believe, using SW rendering because it doesn't support any modern opengl)
Kernel 4.6.2

The whole software stack is whatever comes with arch with the exception of EFL and enlightenment being git.

I'm using Intel N3051..Kernel is 4.6,1

Yep, I've been using fbdev and the issue doesn't occur

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

ApB added a comment.Jun 21 2016, 8:27 AM

Nope. For me doesn't seem to make a difference. :/

ApB added a comment.Jun 22 2016, 2:03 AM

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

am going to reassign this one to @ManMower as he is already knee deep into the slow mouse movement issue.

Sure. I think mike's fixed the other issues on the list, and I know exactly what's causing the cpu burn.

ApB added a comment.Jul 15 2016, 2:20 AM

Derek i still see this. Just finished building git. :/


ApB reopened this task as Open.Jul 15 2016, 2:31 AM

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.

ApB added a comment.Jul 15 2016, 11:58 AM

Log with dereks print stuff.

It is reproduced with the method mentioned above.

@ManMower anything in the logs from @ApB which could help this?

This is one of the last two remaining showstopper bugs for 1.18 right now.

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

ManMower closed this task as Resolved.Jul 27 2016, 6:10 AM

Thanks for the clarification.