Hi,
While testing current Inkscape from trunk I immediately ran into a feature that can easily be perceived as a bug: dragging a gradient slider on 200/400% I see rectangles inside an object come and go all the time. On #inkscape I was told that this is the result of interruptible display introduced to improve responsiveness. My guess is that users might not understand that this is a feature.
I see two ways to minimize public confusion:
1. Provide a better explanation in Release Notes. 2. If possible, make this behavior toggleable, ideally -- introduce a Xara-like "Rendering tradeoff" slider ;-)
What do you think?
Alexandre
On 1/6/07, Alexandre Prokoudine <alexandre.prokoudine@...400...> wrote:
While testing current Inkscape from trunk I immediately ran into a feature that can easily be perceived as a bug: dragging a gradient slider on 200/400% I see rectangles inside an object come and go all the time.
What rectangles? Can you describe them in detail? I _think_ I understand what you are saying but I wouldn't describe that effect as "rectangles" so please clarify.
On 1/7/07, bulia byak wrote:
What rectangles? Can you describe them in detail? I _think_ I understand what you are saying but I wouldn't describe that effect as "rectangles" so please clarify.
It's difficult to explain what you see in a blink of an eye ;-)
When I drag a handle, the object becomes divided into two parts where the bottom part seems to copy the upper part's gradient fill and I guess this is the reason I can see a border between them (objects with linear gradient fill often have top and bottom, so two neighbour equally gradient filled objects don't look like one object). The bottom part is usually ca. 1/8 of the whole object's height.
Alexandre
On 1/7/07, Alexandre Prokoudine <alexandre.prokoudine@...400...> wrote:
When I drag a handle, the object becomes divided into two parts where the bottom part seems to copy the upper part's gradient fill and I guess this is the reason I can see a border between them (objects with linear gradient fill often have top and bottom, so two neighbour equally gradient filled objects don't look like one object). The bottom part is usually ca. 1/8 of the whole object's height.
Yes, and that seems logical to me. It redraws the object on each movement, but it doesn't have enough time to redraw all of it. So it redraws the top, and catches up with the bottom when you slow down or stop. Other vector editors behave in a similar way with complex drawings.
However I just changed it a bit by forcing a full redraw after every 5 interrupted redraws. This I think gives a better compromise between responsiveness and fully updated display. Please test.
On Sun, 2007-01-07 at 18:44 -0400, bulia byak wrote:
On 1/7/07, Alexandre Prokoudine <alexandre.prokoudine@...400...> wrote:
When I drag a handle, the object becomes divided into two parts where the bottom part seems to copy the upper part's gradient fill and I guess this is the reason I can see a border between them (objects with linear gradient fill often have top and bottom, so two neighbour equally gradient filled objects don't look like one object). The bottom part is usually ca. 1/8 of the whole object's height.
Yes, and that seems logical to me. It redraws the object on each movement, but it doesn't have enough time to redraw all of it. So it redraws the top, and catches up with the bottom when you slow down or stop. Other vector editors behave in a similar way with complex drawings.
However I just changed it a bit by forcing a full redraw after every 5 interrupted redraws. This I think gives a better compromise between responsiveness and fully updated display. Please test.
I believe John Bintz also has a patch somewhere which starts the redraw from the corner closest to the mouse, which greatly aids perceived interactivity.
-mental
MenTaLguY wrote:
On Sun, 2007-01-07 at 18:44 -0400, bulia byak wrote:
On 1/7/07, Alexandre Prokoudine <alexandre.prokoudine@...400...> wrote:
When I drag a handle, the object becomes divided into two parts where the bottom part seems to copy the upper part's gradient fill and I guess this is the reason I can see a border between them (objects with linear gradient fill often have top and bottom, so two neighbour equally gradient filled objects don't look like one object). The bottom part is usually ca. 1/8 of the whole object's height.
Yes, and that seems logical to me. It redraws the object on each movement, but it doesn't have enough time to redraw all of it. So it redraws the top, and catches up with the bottom when you slow down or stop. Other vector editors behave in a similar way with complex drawings.
However I just changed it a bit by forcing a full redraw after every 5 interrupted redraws. This I think gives a better compromise between responsiveness and fully updated display. Please test.
I believe John Bintz also has a patch somewhere which starts the redraw from the corner closest to the mouse, which greatly aids perceived interactivity.
-mental
I do, but I haven't looked at it in a while, say in the last three months or so. I know there was a lot that needed to be tweaked to get it working 100%, but it did help when the redraws were really slowed down. bulia, if you're interested, I can clean it up and send it along so you can see how it works.
John
On 1/8/07, John Bintz <jcoswell@...1414...> wrote:
I do, but I haven't looked at it in a while, say in the last three months or so. I know there was a lot that needed to be tweaked to get it working 100%, but it did help when the redraws were really slowed down. bulia, if you're interested, I can clean it up and send it along so you can see how it works.
Surely I'm interested. Insisting on left-right top-down redraw in all cases is really a stupid idea now that I think of it - we could just as easily paint it in any order.
bulia byak said:
Surely I'm interested. Insisting on left-right top-down redraw in all cases is really a stupid idea now that I think of it - we could just as easily paint it in any order.
I'll have to rework the code so that it works with sp_canvas_paint_rect_internal, as opposed to sp_canvas_paint_rect, but that shouldn't take too long to do. I'll see if I can get something together tonight or tomorrow night.
bulia byak said:
Surely I'm interested. Insisting on left-right top-down redraw in all cases is really a stupid idea now that I think of it - we could just as easily paint it in any order.
Here's a patch that will change the redraw direction depending on the mouse pointer's position relative to the center of the redraw area. It will start from the corner closest to the mouse pointer and paint away from that corner. If the mouse is in the middle vertical third of the redraw area, the optimization isn't as noticeable, but on the corners, the difference is very visible. This is as far as I got on the first run, and I believe a further optimization would be to switch the repaint order (from rows -> columns to columns -> rows) if the mouse is farther left/right from the center than it is up/down from the center. This should solve the issue with the middle third of the rectangle not being drawn as often. Then, the only problem area would be the very middle of the repaint area.
John
Thanks! Works somewhat funny and takes some getting used to, but gives a noticeable improvement in interactivity. We could improve it further - for example it need not paint in horizontal strips, they could be vertical if it makes sense. When mouse is in the center, we could start from the center and paint towards the edges, etc.
However I don't want to commit it now, because I'd prefer 0.45 out as soon as possible. Will you please submit the patch to the tracker? I will commit it after 0.45.
Thanks again!
On 1/8/07, bulia byak wrote:
Yes, and that seems logical to me. It redraws the object on each movement, but it doesn't have enough time to redraw all of it. So it redraws the top, and catches up with the bottom when you slow down or stop. Other vector editors behave in a similar way with complex drawings.
However I just changed it a bit by forcing a full redraw after every 5 interrupted redraws. This I think gives a better compromise between responsiveness and fully updated display. Please test.
I don't see much difference (as of revision 13621), but then you have a valid point about complex drawings, so maybe I worry too much.
Alexandre
participants (4)
-
Alexandre Prokoudine -
bulia byak -
John Bintz -
MenTaLguY