View Single Post
Old 12-23-2009, 07:42 PM   #2
Valloric
Created Sigil, FlightCrew
Valloric ought to be getting tired of karma fortunes by now.Valloric ought to be getting tired of karma fortunes by now.Valloric ought to be getting tired of karma fortunes by now.Valloric ought to be getting tired of karma fortunes by now.Valloric ought to be getting tired of karma fortunes by now.Valloric ought to be getting tired of karma fortunes by now.Valloric ought to be getting tired of karma fortunes by now.Valloric ought to be getting tired of karma fortunes by now.Valloric ought to be getting tired of karma fortunes by now.Valloric ought to be getting tired of karma fortunes by now.Valloric ought to be getting tired of karma fortunes by now.
 
Valloric's Avatar
 
Posts: 1,978
Karma: 350515
Join Date: Feb 2008
Device: Sony Reader PRS 505
Quote:
Originally Posted by lol View Post
Hello,

This is my first post, and I'm glad to have found such a vibrant forum community.
Let me be the first to welcome you to the forum.

Quote:
Originally Posted by lol View Post
When editing a .epub, 'paste' takes (what I find to be) a long time - about 10 seconds for text to appear in the document after a 'CTRL-V'.
Yeah, this is a problem. See, Sigil embeds Webkit, the browser engine. It's the basis for the Book View. In fact, it is the Book View. So Book View inherits some of it's shortcomings.

One of them is pasting rich text, especially from Word. It can be slow. I can't really work around this.

But 10 seconds is way too much I must agree. I've never experienced such a big slowdown. Then again, I'm not running it on a netbook.

Quote:
Originally Posted by lol View Post
Similarly, deleting characters or a word is very responsive but it takes about 20 - 30 seconds for the text to realign after deleting a blank line. I'm curious as to why Sigil would take such a long time to delete a blank line when deleting a word takes no time at all.
This I completely agree with: it's god-awful slow. Again, webkit. From what I can gather, it uses a really stupid algorithm when searching for elements to merge. Again, not something I can work around.

The bigger the flow your editing, the slower it is. The relationship is more than just linear, so on larger files the slowdown can become huge. But! Sigil 0.2.0 will bring multi-flow oriented editing and your flows will then be much smaller, and hence the lag as well.

Some time in the future I intend to make a personal fork of Qt and start working on these problems in their Webkit port. The problem is that people few use Webkit for rich text editors, and fewer still use the Qt port. So not much work is going towards this from the official devs.

It's up to me to fix these problems, and it's a large undertaking. Merely getting familiar with the Webkit codebase (hundreds of thousands of LOC) will take time. And then I have to find the root causes of the issues, and then fix them. This is all on top of regular Sigil development... so not soon.
Valloric is offline   Reply With Quote