I really like a lot of the changes I see in 0.46, like dialogs opening to the right instead of floating. And is the layers dialog new? If not I must have over looked it. I definitely like the new tweak brush.
But here is something that is really bugging me. In part I just made a stupid mistake, but also this is a really stupid behavior in inkscape.
I spent the last hour working on a drawing (and here is the really stupid part for me) without saving.
Then I turned up the blur a little. Well, I meant to turn it up a little. But I twitched, and apparently turned it up a lot. And now I see three things I would really like.
First, inkscape is pegging one of my CPUs (core 2 duo, 2 gigs of ram). And it has been pegging this CPU for more then 10 minutes now.
Meanwhile, the display isn't updating at all. Not just the canvas, but the dialogs, the drawing tools, the menus, none of them are redrawing.
Third, there doesn't seem to be anyway to cancel the operation without quitting (which I obviously don't want to do because I stupidly didn't save).
Actually, in another instance of inkscape, I see that the blur slider only goes to a hundred, and at 100 it is perfectly snappy with two strokes. The drawing that is pegging the machine only has a few dozen strokes, so it seems that complexity here is rather non-linear.
So, here are somethings I think should be added:
First, perhaps it would be possible for Inkscape to auto-save to /tmp or someplace when the user hasn't explicitely saved anywhere yet.
Second, perhaps there should be some bound for render time.
Third, the rest of the GUI should at least redraw, even if the canvas doesn't, and it should at least respond to some commands. Undo or save would be commands I might consider trying to execute during a long render.
Fourth, would it be possible to thread this? Perhaps one thread for the GUI and one for rendering as a starting point? It would be great to thread rendering, but I can see how that wouldn't be so straight forward.
Fifth, is there any chance of using something to accelerate certain drawing operations, like blurs? Possibly with C code (which could then have a generic version and compile time select between that or a SSE version or an Altivec version)? Or something like Pyscho, pyrex, or pypy?
Sixth, this is probably more of a personal taste request, but perhaps the blur slider could be logarithmic? Creatively, the difference between 60 and 62 is pretty small, but the differences at the low end are big.
On Sat, 2008-04-12 at 16:38 -0400, Joshua Boyd wrote:
I really like a lot of the changes I see in 0.46, like dialogs opening to the right instead of floating.
If you're running *NIX and look at the file ~/.inkscape/preferences.xml in the group <group id="dialogs"> there are some groups with `state="1"` and `state="2"`
Those with `state="2"` are attached to the right, and those with `state="1"` are floating.
So, if you change them, you can control whether they float or not.
But before you start, do: `cp ~/.inkscape/preferences.xml ~/.inkscape/old-preferences.xml`
That way you have a copy in case you mess up.
Joshua Boyd wrote:
... Then I turned up the blur a little. Well, I meant to turn it up a little. But I twitched, and apparently turned it up a lot. And now I see three things I would really like.
First, inkscape is pegging one of my CPUs (core 2 duo, 2 gigs of ram). And it has been pegging this CPU for more then 10 minutes now.
Meanwhile, the display isn't updating at all. Not just the canvas, but the dialogs, the drawing tools, the menus, none of them are redrawing.
If you find blur to be slow in general then you may want to look at the blur quality options (under Filters in the Inkscape preferences). While editing the decrease in quality is often not that serious, and for export it always uses the best quality anyway.
Third, there doesn't seem to be anyway to cancel the operation without quitting (which I obviously don't want to do because I stupidly didn't save).
Actually, in another instance of inkscape, I see that the blur slider only goes to a hundred, and at 100 it is perfectly snappy with two strokes. The drawing that is pegging the machine only has a few dozen strokes, so it seems that complexity here is rather non-linear.
It depends, but it should behave roughly linear in the size (in pixels) of the object it is blurring. So blurring an object that is 100x100 pixels (on screen) will take approximately 4 times as much time as blurring an object that is 50x50 (assuming both blurs have the same blur radius, if you have a very large blur radius the output image is enlarged by quite a bit, making it very slow). In practice blurring larger areas is a bit slower than that, but it shouldn't be much slower. So if you have a file that reproducibly takes extremely long to blur I'd love to take a look to see what's going on.
So, here are somethings I think should be added:
First, perhaps it would be possible for Inkscape to auto-save to /tmp or someplace when the user hasn't explicitely saved anywhere yet.
Second, perhaps there should be some bound for render time.
That could be tricky, for example with blur, would you want half the image blurred?
Third, the rest of the GUI should at least redraw, even if the canvas doesn't, and it should at least respond to some commands. Undo or save would be commands I might consider trying to execute during a long render.
Would indeed be nice. Perhaps something akin to the DoEvents() function in VB could be used in long operations, but it would not be easy to make this work properly (for example, either you have to make sure you prevent the user from doing anything that would interfere with rendering, or you would have to deal with any sort of user input).
Fourth, would it be possible to thread this? Perhaps one thread for the GUI and one for rendering as a starting point? It would be great to thread rendering, but I can see how that wouldn't be so straight forward.
Exactly :)
Fifth, is there any chance of using something to accelerate certain drawing operations, like blurs? Possibly with C code (which could then have a generic version and compile time select between that or a SSE version or an Altivec version)? Or something like Pyscho, pyrex, or pypy?
Blur is already relatively fast (it is in C(++) btw). It would no doubt be possible to accelerate it further using SSE or something similar, it just needs someone to implement it.
participants (3)
-
Jasper van de Gronde -
Joshua Boyd -
Mr. Shawn H. Corey