Change Details

Sometimes drawing leaves an initial spot of 100% pressure. Example: https://dl.dropboxusercontent.com/u/37777793/krita/kf5-brush.png Is this somewhat inconsistent? Unfortunately I'm not sure I can fix this myself though I wrote the new tablet sensor handler because I can't reproduce it on my setup. I can add some more comments to the source and take another look over it. This is caused by a MouseMove event occurring before a TabletMove event. Unfortunately there is no guarantee that these events will be nicely ordered. This is one algorithm that might fix it. - Qt's MousePress events are a special sort of event. (Less generously one might call them, "screwed up.") The meaning of these events depends on the event immediately following. - If the event after a MousePress event is a tablet event, the MousePress was synthetic, so toss it. If the event was a MouseMove, it was a real mouse click, so keep it. - The solution is to store one MousePress event in the EventEater until the next event arrives. Once it sees the event following, it will know whether to forward the MouseMove event or to toss it away. - If events can get more disordered than two, the above solution will not work. On the other hand, that would be preposterous, and I'd sooner file a bug report in Qt or Xorg than write a workaround in Krita.

Sometimes drawing leaves an initial spot of 100% pressure. Example: https://dl.dropboxusercontent.com/u/37777793/krita/kf5-brush.png Is this somewhat inconsistent? Unfortunately I'm not sure I can fix this myself though I wrote the new tablet sensor handler because I can't reproduce it on my setup. I can add some more comments to the source and take another look over it. This is caused by a MouseMove event occurring before a TabletMove event. Unfortunately there is no guarantee that these events will be nicely ordered. This is one algorithm that might fix it. - Qt's MousePress events are a special sort of event. (Less generously one might call them, "screwed up.") The meaning of these events depends on the event immediately following. - If the event after a MousePress event is a tablet event, the MousePress was synthetic, so toss it. If the event was a MouseMove, it was a real mouse click, so keep it. - The solution is to store one MousePress event in the EventEater until the next event arrives. Once it sees the event following, it will know whether to forward the MouseMove event or to toss it away. - If it is possible that the arrival of events can be off by more than one, the above solution will not work. On the other hand, that would be preposterous, so I will not worry about it.

Sometimes drawing leaves an initial spot of 100% pressure. Example: https://dl.dropboxusercontent.com/u/37777793/krita/kf5-brush.png Is this somewhat inconsistent? Unfortunately I'm not sure I can fix this myself though I wrote the new tablet sensor handler because I can't reproduce it on my setup. I can add some more comments to the source and take another look over it. This is caused by a MouseMove event occurring before a TabletMove event. Unfortunately there is no guarantee that these events will be nicely ordered. This is one algorithm that might fix it. - Qt's MousePress events are a special sort of event. (Less generously one might call them, "screwed up.") The meaning of these events depends on the event immediately following. - If the event after a MousePress event is a tablet event, the MousePress was synthetic, so toss it. If the event was a MouseMove, it was a real mouse click, so keep it. - The solution is to store one MousePress event in the EventEater until the next event arrives. Once it sees the event following, it will know whether to forward the MouseMove event or to toss it away. - If it is possible that the arrival of events can get more disorderedbe off by more than twoone, the above solution will not work. On the other hand, that would be preposterous, and I'd sooner file a bug report in Qt or Xorg than write a workaround in Kritaso I will not worry about it.