I'm flooded by a stream of warnings like
** (inkscape:27965): WARNING **: Event latency reached 3.290566 sec
What am I supposed to do with them?
On Jul 8, 2008, at 8:18 PM, bulia byak wrote:
I'm flooded by a stream of warnings like
** (inkscape:27965): WARNING **: Event latency reached 3.290566 sec
What am I supposed to do with them?
Oooh, that sounds bad.
Off hand I'd suggest running in gdb with --g-fatal-warnings and checking what the backtrace on that sloooooooooow event is.
On Wed, 2008-07-09 at 00:18 -0300, bulia byak wrote:
I'm flooded by a stream of warnings like
** (inkscape:27965): WARNING **: Event latency reached 3.290566 sec
What am I supposed to do with them?
That's from my instrumentation for debugging the calligraphy slowness/temporary hangs. You're actually seeing latencies that high without hangs?
-mental
On Sat, Jul 19, 2008 at 1:48 AM, MenTaLguY <mental@...3...> wrote:
That's from my instrumentation for debugging the calligraphy slowness/temporary hangs. You're actually seeing latencies that high without hangs?
And even higher. I have a slow computer.
So what's the purpose of these warnings? To tell me I'm running slow? I feel it without any warnings :)
On Jul 18, 2008, at 9:48 PM, MenTaLguY wrote:
On Wed, 2008-07-09 at 00:18 -0300, bulia byak wrote:
I'm flooded by a stream of warnings like
** (inkscape:27965): WARNING **: Event latency reached 3.290566 sec
What am I supposed to do with them?
That's from my instrumentation for debugging the calligraphy slowness/temporary hangs. You're actually seeing latencies that high without hangs?
Yes. And I started seeing some myself. The odd thing was that they started up after I'd had the tool open for a bit, then would slowly climb higher even though I wasn't doing anything taxing.
In those cases it was looking like some time was not being properly cleared and was being wrongly checked. Or perhaps like an array/queue was being used but the head and tail were drifting out of sync, etc.
On Jul 18, 2008, at 10:39 PM, Jon A. Cruz wrote:
Yes. And I started seeing some myself. The odd thing was that they started up after I'd had the tool open for a bit, then would slowly climb higher even though I wasn't doing anything taxing.
In those cases it was looking like some time was not being properly cleared and was being wrongly checked. Or perhaps like an array/queue was being used but the head and tail were drifting out of sync, etc.
Ohh! I saw it just now when drawing a single rectangle and then exporting as bitmap.
Perhaps it could also be looking like it's rounding off poorly and accumulating error.
On Fri, 2008-07-18 at 22:39 -0700, Jon A. Cruz wrote:
In those cases it was looking like some time was not being properly cleared and was being wrongly checked. Or perhaps like an array/queue was being used but the head and tail were drifting out of sync, etc.
Hm, could you sanity-check src/debug/gdk-event-latency-tracker.cpp for me? As far as I can tell it is correct, but maybe there is some weird issue. If you're seeing actual latencies that high, there should be noticable lag in the UI during that time.
(The latency is estimated, since we don't have access to the actual event clock and must guess at it, but the code is intended to try to underestimate latency, not overestimate it...)
-mental
On Jul 18, 2008, at 10:56 PM, MenTaLguY wrote:
Hm, could you sanity-check src/debug/gdk-event-latency-tracker.cpp for me? As far as I can tell it is correct, but maybe there is some weird issue. If you're seeing actual latencies that high, there should be noticable lag in the UI during that time.
(The latency is estimated, since we don't have access to the actual event clock and must guess at it, but the code is intended to try to underestimate latency, not overestimate it...)
I think I'm definitely seeing some time-skew of some sort. My new minimal test case is to bring up Inkscape, go on to do other stuff, then go back to Inkscape after a few minutes. Then as soon as I wiggle the mouse over the canvas those warnings start to come out. Much easier to track down I believe. So I'll try to get the code looked over and some debugging of it done this week. I'm thinking that with knowing where in the code to poke and having a simple case to reproduce will allow it to be hunted down quickly.
participants (3)
-
bulia byak -
Jon A. Cruz -
MenTaLguY