[prev in list] [next in list] [prev in thread] [next in thread]
List: kde-kimageshop
Subject: Re: On Time and Events
From: Dmitry Kazakov <dimula73 () gmail ! com>
Date: 2014-12-20 19:29:58
Message-ID: CAEkBSfUBXixHk7fzaN659QA_AvmkOcC4yL6v13CdCgqF+SjSmA () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
As I said above, system timestamps make the situation noticeably
> better (see example images, I couldn't manage to get really awful
> lines with it, so it's a better), but it's not a silver bullet and it
> needs to be complemented with proper handling of slightly off values.
>
> Besides, I don't have better arguments for this refactoring than :
> - it would de-obfuscate KisInputManager/KisToolProxy
> - having a unique consistent complete pointer event interface is
> better done early and made available to all Krita components
> - ...my guts are telling me to, and my guts never lie
>
> So yeah, it's probably not critical beyond the ease of implementing
> timestamps correctly, I just think it would help in reducing the
> unneeded complexity in several parts of the code.
>
Well, the timestamps are quite an expensive refactoring and you'll spend
about a month of work on it. I would look at it in the following way:
1) First do speed filtering. You need to do it anyway :)
2) Then compare the quality of the filtering with your proof of concept
timestamps patch activated and not. If the quality difference is really
worth it, we do it :) If not, we'll better spend time on something else,
e.g. on openCL support or something like that :)
> The problem is that InputManager is an event filter for *Canvas
> events*, so it only happens when your cursor interacts with the
> canvas. Reproduce these sequences with a two ended stylus :
> - Initial state : preset A
> - move cursor with stylus end to the preset box
> - flip to eraser without moving over the canvas
> - choose preset B
> --- Branch 1
> - move to canvas, draw with B
> - flip again to stylus and draw with... B ? <-- Oops, should be A
> --- Branch 2 (repeat first steps)
> - flip again to stylus without moving over the canvas
> - choose preset C
> - move to the canvas, draw with C
> - flip to eraser and draw with.... C ? <-- Oops, should be B
>
I got what you mean :) Yes, it is a problem, but I'm not sure the painters
face it that often.
--
Dmitry Kazakov
[Attachment #5 (text/html)]
<div dir="ltr"><br><div class="gmail_extra"><br><div \
class="gmail_quote"><br><blockquote class="gmail_quote" style="margin:0 0 0 \
.8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""> </span>As I said \
above, system timestamps make the situation noticeably<br> better (see example \
images, I couldn't manage to get really awful<br> lines with it, so it's a \
better), but it's not a silver bullet and it<br> needs to be complemented with \
proper handling of slightly off values.<br> <br>
Besides, I don't have better arguments for this refactoring than :<br>
- it would de-obfuscate KisInputManager/KisToolProxy<br>
- having a unique consistent complete pointer event interface is<br>
better done early and made available to all Krita components<br>
- ...my guts are telling me to, and my guts never lie<br>
<br>
So yeah, it's probably not critical beyond the ease of implementing<br>
timestamps correctly, I just think it would help in reducing the<br>
unneeded complexity in several parts of the \
code.<br></blockquote><div><br></div><div><br>Well, the timestamps are quite an \
expensive refactoring and you'll spend about a month of work on it. I would look \
at it in the following way:<br><br></div><div>1) First do speed filtering. You need \
to do it anyway :)<br></div><div>2) Then compare the quality of the filtering with \
your proof of concept timestamps patch activated and not. If the quality difference \
is really worth it, we do it :) If not, we'll better spend time on something \
else, e.g. on openCL support or something like that :)<br></div><div><br> \
</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc \
solid;padding-left:1ex"> The problem is that InputManager is an event filter for \
*Canvas<br> events*, so it only happens when your cursor interacts with the<br>
canvas. Reproduce these sequences with a two ended stylus :<br>
- Initial state : preset A<br>
- move cursor with stylus end to the preset box<br>
- flip to eraser without moving over the canvas<br>
- choose preset B<br>
--- Branch 1<br>
- move to canvas, draw with B<br>
- flip again to stylus and draw with... B ? <-- Oops, should be A<br>
--- Branch 2 (repeat first steps)<br>
- flip again to stylus without moving over the canvas<br>
- choose preset C<br>
- move to the canvas, draw with C<br>
- flip to eraser and draw with.... C ? <-- Oops, should be B<br \
clear="all"></blockquote></div><br></div><div class="gmail_extra">I got what you mean \
:) Yes, it is a problem, but I'm not sure the painters face it that \
often.<br></div><div class="gmail_extra"><br>-- <br><div \
class="gmail_signature">Dmitry Kazakov</div> </div></div>
_______________________________________________
Krita mailing list
kimageshop@kde.org
https://mail.kde.org/mailman/listinfo/kimageshop
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic