NEW: interruptible display for better interactivity

Just committed:
* Interruptible display: Previously, Inkscape could not do anything until it finishes the current screen redraw. Now the redraw is made interruptible, so that Inkscape responds to mouse and keyboard input and can abort the current redraw and start over if you do some screen-changing operation. As a result, Inkscape now feels much snappier and more interactive.
So, while redraw is not really any faster now, it _feels_ much faster, especially for things like zooming, scrolling, etc. Enjoy.
I fixed a couple bugs that were exposed by this change, but there may be more. In particular I suspect there might be a crash when you quit Inkscape while it's redrawing. I got this crash a couple times but it's very hard to nail it down. If you can cause it reproducibly please let me know. Other than that, it's working perfectly for me in the last few days.
Thanks to Mental who suggested this change :)

bulia byak escribió:
Just committed:
- Interruptible display: Previously, Inkscape could not do anything
until it finishes the current screen redraw. Now the redraw is made interruptible, so that Inkscape responds to mouse and keyboard input and can abort the current redraw and start over if you do some screen-changing operation. As a result, Inkscape now feels much snappier and more interactive.
So, while redraw is not really any faster now, it _feels_ much faster, especially for things like zooming, scrolling, etc. Enjoy.
I fixed a couple bugs that were exposed by this change, but there may be more. In particular I suspect there might be a crash when you quit Inkscape while it's redrawing. I got this crash a couple times but it's very hard to nail it down. If you can cause it reproducibly please let me know. Other than that, it's working perfectly for me in the last few days.
Thanks to Mental who suggested this change :)
This looks indeed interesting, however, wouldn't it be best to address the slow redraw issue? Or is it a Cairo/GTK problem rather than internal Inkscape's? (I would assume it is related to Cairo/GTK).
I recently saw a comparative chart about various vector engines (alas it is biased) at the Xara project's website, an it seems that Cairo is still a tad too slow (compared even to Microsoft's GDI), and Xara's engine seems to be the fastest (again, this comparative is biased). You can see comparatives here: www.xaraxtreme.org (plus the Open Source announcement), It would be interesting to have Cairo perform as fast.

On 8/3/06, Gian Paolo Mureddu <thetargos@...155...> wrote:
This looks indeed interesting, however, wouldn't it be best to address the slow redraw issue?
It is being addressed all the time. I think the redraw is now about twice as fast overall, compared to 0.43.
Or is it a Cairo/GTK problem rather than internal Inkscape's? (I would assume it is related to Cairo/GTK).
No, we don't use Cairo for rendering yet.

Gian Paolo Mureddu wrote:
This looks indeed interesting, however, wouldn't it be best to address the slow redraw issue? Or is it a Cairo/GTK problem rather than internal Inkscape's? (I would assume it is related to Cairo/GTK).
No, this is Inkscape's internal renderer.
I recently saw a comparative chart about various vector engines (alas it is biased) at the Xara project's website, an it seems that Cairo is still a tad too slow (compared even to Microsoft's GDI), and Xara's engine seems to be the fastest (again, this comparative is biased). You can see comparatives here: www.xaraxtreme.org (plus the Open Source announcement), It would be interesting to have Cairo perform as fast.
It would be interesting to see a couple things with that performance comparison. First, a comparison made with the most current stable Cairo. Second, a comparison made of Cairo w/ the Glitz back-end. From what I've heard, the performance of Cairo w/ Glitz is approaching the speed of Xara, however, that is just hearsay until I see it for myself. ;)
-Josh

On Thu, 2006-08-03 at 13:49 -0500, Gian Paolo Mureddu wrote:
This looks indeed interesting, however, wouldn't it be best to address the slow redraw issue?
No matter how fast you make the renderer, there are always going to be some complex documents for which it is too slow. We may as well deal reasonably with those cases.
-mental

Bulia, as always, this is totally subtly awesome!
I haven't tried this yet, but I'm hoping that this also enables some quick keyboard shortcut to stop and operation...
Doing demos here at Siggraph with huge tracing stuck my system for too long and had to kill it a few times. I wish I could have just hit ESC and gotten out of the computation and waiting.
The other thought is to have some type of progress bar for processes that take long in the bottom of the status bar, with a cancel button to the right of this progress indicator so one could also click to stop a process.
Jon
On Thu, 2006-08-03 at 15:08 -0300, bulia byak wrote:
Just committed:
- Interruptible display: Previously, Inkscape could not do anything
until it finishes the current screen redraw. Now the redraw is made interruptible, so that Inkscape responds to mouse and keyboard input and can abort the current redraw and start over if you do some screen-changing operation. As a result, Inkscape now feels much snappier and more interactive.
So, while redraw is not really any faster now, it _feels_ much faster, especially for things like zooming, scrolling, etc. Enjoy.
I fixed a couple bugs that were exposed by this change, but there may be more. In particular I suspect there might be a crash when you quit Inkscape while it's redrawing. I got this crash a couple times but it's very hard to nail it down. If you can cause it reproducibly please let me know. Other than that, it's working perfectly for me in the last few days.
Thanks to Mental who suggested this change :)
participants (5)
-
bulia byak
-
Gian Paolo Mureddu
-
Jon Phillips
-
Joshua A. Andler
-
MenTaLguY