Document property's spinboxes' autorepeat not updating correctly

[JeromeBanal]

Dear all,

Using http://inkscape.modevia.com/win32-snap/inkscape-0801200900.7z with Windows XP Pro SP2.
I suppose it is Windows only or the developers would have noticed.

Not a crash bug here but still a very incovenient one.

First of all, some defs to be well understood:

1. I call spinbox an input box that has two arrows to increase/decrease the value it stores.
2. By autorepeat, I mean that a spinbox is expected to continuously increase the value in the input
box, providing visual feedback, if I do not release my mouse button after clicking on one of the
arrow and stay over it.

2 is indeed the behaviour nearly everywhere, like on the tools parameter spinbox or on the bitmap
vectorizer window, but not in a couple of places.

One is the document property, the other is the opacity spinbox at the bottom of the main window.
In those, the value seems to increase as expected in the background but the value displayed by
the input box is not updated until the mouse button is released (the opacity one sometimes
displays a few steps, the document windows never).

This is a real pain as you have to guesstimate the current value of the field.

Hope you can reproduce this,
Thanks for your time,
Kind regards,
Jerome

[Bryce Harrington (bryce)]

Confirmed on linux with current svn, at least with the opacity spinbox. What is the "document property"?

[JeromeBanal (jerome-banal)]

Hi Bryce,

Sorry, I use a localized version so I have back-translated it :)
In Inkscape-0.45.1+0.46pre1-1.win32.exe, it's called "Document Properties...", in the "File" menu.
I have found other dialogs that display the incorrect behaviour, like "Filter Effects" (in "Object").

And yet another incorrect behaviour: "Width" in "Path Effects..." dialog (in "Path" menu) has simply no auto-repeat at all.

Even weirder: if I apply a blur effect to a rectangle, than the spinboxes (for size, position...) in the toolbar start to behave with the same buggy behaviour of not updating the value whereas they were working correctly before!

Jerome

[JeromeBanal (jerome-banal)]

I have tried 0.46-pre2.1 for Windows today to verify the status of this bug. It is still present but this test has brought me a better understanding of the problem.

I use a laptop those CPU speed is throttled by its temperature.
I have noticed here that when the CPU is cold, most spinboxes behaves correctly or almost correctly with just a few hipcups, but when the CPU gets hot, hence slow, all spinboxes show at best hipcups or start to not update the number in the spinbox during autorepeat.

My conclusion is: the redraw of the spinboxes seems asynchronous with the callback execution and has low priority compared to it, so when there is not a lot of power and the tasks to execute is CPU intensive (like the blur effect mentioned previously as triggering a bad behaviour), the spinboxes do not get enough time to update themselves. In heavy cases of course, the surface refresh due to the callback is not fully done in time either but that's to be expected to retain interactivity.

This behaviour is good enough when your value has a net visual impact and you trust your eyes enough -you might even get a slightly better refresh rate as you spare a little bit of processing-, but bad when you want/need to be more precise, deal with subtle tweaking or can't fully trust your eyes (people with astigmatism for example).

Also the behaviour reported about the Width spinbox in Path Effect dialog is still here.

If you need any other piece of information to make the bug not "incomplete" hence not expirable, just ask.

Jerome

[Alex Valavanis (valavanisalex)]

This appears to be a duplicate of bug #553263 so I'll mark it as such. If you believe the duplicate status is a mistake, please feel free to revert this change.