Ted,
Yesterday for the first time I tried live-update effect on a large slow document (about 1Mb with lots of blur etc). It was a torture. I could not even adjust the number of paragraphs because it froze on every change for a long time.
You made the effects themselves asynchronous - that is nice. But in situations like this, the actual effect run takes only a small fraction of the total time; a lot more time is spent by Inkscape itself on saving and then reloading the large file. And since Inkscape itself is not asynchronous at all, this freezes everything including the effect dialog.
Sorry for pounding on it, but I think I've proven enough by now that the checkbox must be there and off by default :)
On 7/11/07, bulia byak <buliabyak@...400...> wrote:
Ted,
Yesterday for the first time I tried live-update effect on a large slow document (about 1Mb with lots of blur etc). It was a torture. I could not even adjust the number of paragraphs because it froze on every change for a long time.
You made the effects themselves asynchronous - that is nice. But in situations like this, the actual effect run takes only a small fraction of the total time; a lot more time is spent by Inkscape itself on saving and then reloading the large file. And since Inkscape itself is not asynchronous at all, this freezes everything including the effect dialog.
Sorry for pounding on it, but I think I've proven enough by now that the checkbox must be there and off by default :)
-- bulia byak Inkscape. Draw Freely. http://www.inkscape.org
It might even be worth having it be able to be disabled by the extension, there are some that are never going to make sense to be live, so having it as livepreview=no in the extension stops wierdness occuring if someone turns off a checkbox.
On Wed, 2007-07-11 at 11:58 -0400, bulia byak wrote:
Yesterday for the first time I tried live-update effect on a large slow document (about 1Mb with lots of blur etc). It was a torture. I could not even adjust the number of paragraphs because it froze on every change for a long time.
Yes, I can see that.
What would everyone think about changing the XML parser to run queued GTK events ever 100 or so nodes? It would make loading SVG files slightly slower (most of the time there'd be no events) but it might make the application appear more responsive (when loading in general also, not just for scripted effects). Thoughts?
Sorry for pounding on it, but I think I've proven enough by now that the checkbox must be there and off by default :)
Well, I'm planning on putting the checkbox and the status in -- I'm hoping they'll be so excellent that we can discuss the default state a little after that :)
It will take a little bit though, there's some messy context stuff that might cause me to restructure stuff slightly. :(
--Ted
On 7/11/07, Ted Gould <ted@...11...> wrote:
What would everyone think about changing the XML parser to run queued GTK events ever 100 or so nodes? It would make loading SVG files slightly slower (most of the time there'd be no events) but it might make the application appear more responsive (when loading in general also, not just for scripted effects). Thoughts?
That's very dangerous IMHO. Running GTK events means running UI events, and that might involve any kind of change in the document. I don't think changing the content of a document while it's not yet fully loaded is a good idea. I did something similar for interruptible display - but there, a non-document-changing operation (rendering) is interrupted by a potentially document-changing operation, and if it indeed changed the document, the rendering simply aborts and starts anew. Even that revealed a ton of bugs and crashes that had to be fixed (including a crash in GTK itself). With your proposal, we'll have one document-changing operation (loading) interrupted by another document-changing operation - and I don't think it's possible to properly sort this out at all.
On Wed, 11 Jul 2007 13:54:55 -0400, "bulia byak" <buliabyak@...400...> wrote:
Even that revealed a ton of bugs and crashes that had to be fixed (including a crash in GTK itself). With your proposal, we'll have one document-changing operation (loading) interrupted by another document-changing operation - and I don't think it's possible to properly sort this out at all.
I looked at implementing this a while back and came to the same conclusion.
Incremental loading is still something I'd like to do eventually (particularly for the sake of preview), but it's not yet clear to me how we could get from here to there successfully. We'd at least need a facility to restrict verb invocation on a per-document basis, but that doesn't help us for actions which aren't tied to verbs yet.
-mental
On Wed, 2007-07-11 at 11:47 -0700, MenTaLguY wrote:
On Wed, 11 Jul 2007 13:54:55 -0400, "bulia byak" <buliabyak@...400...> wrote:
Even that revealed a ton of bugs and crashes that had to be fixed (including a crash in GTK itself). With your proposal, we'll have one document-changing operation (loading) interrupted by another document-changing operation - and I don't think it's possible to properly sort this out at all.
I looked at implementing this a while back and came to the same conclusion.
Incremental loading is still something I'd like to do eventually (particularly for the sake of preview), but it's not yet clear to me how we could get from here to there successfully. We'd at least need a facility to restrict verb invocation on a per-document basis, but that doesn't help us for actions which aren't tied to verbs yet.
Can GTK+ do this for us by making the whole window insensitive?
--Ted
On Wed, 11 Jul 2007 14:36:23 -0700, Ted Gould <ted@...11...> wrote:
Can GTK+ do this for us by making the whole window insensitive?
Up to a point, but there are still corner cases. I'd feel better if the restriction could be enforced at the SPObject and XML layers.
It might be feasible if the transaction model were a lot stricter.
-mental
participants (4)
-
bulia byak -
john cliff -
MenTaLguY -
Ted Gould