Slow editing
 

I am editing an .epub, with Sigil, and it takes 15" to delet a "return". What is wrong? Thanks

Could be any or all of the following:

1. Your computer is too slow or it is doing something else at the same time that slows it down. Reboot and try again, before starting any other tasks. Try on another computer.

2. The .epub file is corrupt. Try editing another file and see if that is faster.

3. You are working with the file stored on slow memory. Copy the .epub to the desktop and edit it there.

4. The Sigil install is bad - reinstall and try again. Perhaps even a more recent version.

5. Something else...

if the file it's big, then it's normal
Sigil code need to be optimized, i think

Webkit needs to be optimized. I can only try to work around its deficiencies. That's why 0.2.0 will move away from single-flow editing towards multi-flow editing, to mitigate the performance impact that large XHTML files bring to Webkit "contentEditable" editing.

Also, it's much much speedier to edit in code view. You might try that.

that kind of defeats the purpose of a WYSIWYG editor, no?

i'm also experiencing problems. the app is slow to the point that it is absolutely unusable. it takes around 20 seconds to load a file if i'm lucky - half the time it just stops responding. once i get an epub to load, i can't even scroll without having to wait another 10 seconds for a refresh, let alone edit anything.

if i switch to code view everything is fine.

tried on half a dozen epub files, no luck at all.

Windows 7 x86

I feel for you. Believe me, I do. On the files I edit, I basically get the same user experience. Makes me infinitely sad and frustrated. Pissed off, as well.

Wait for 0.2.0. It'll be out in about three weeks, and it's a joy to use: loading huge files takes about 2 seconds, and since the XHTML files are not concatenated into one large one but left separate, you merely open the one you want to edit in a tab and it works reasonably fast. Several times faster than before, actually. This is because the smaller the flow loaded, the faster WebKit can respond. It gets slower exponentially depending on the size.

And since content files are now separate, I can multi-thread the loading process: every XHTML file needs to go through Tidy, and for each one a functor "task" is created. So 50 different content files, 50 different "tasks". These are then handed off to a thread pool that munches them in parallel until they are all done. The number of threads in the thread pool is equal the number of logical CPUs (cores and HT count) on your machine. So if you have a quad-core with HT (8 logical CPUs), it's going to get the loading done 8 times faster than some single-core machine. And it scales linearly. But even on my measly old Core 2 Duo, it loads large files in 2 seconds, not 20.

There's a great amount of MT optimizations that can be employed in this kind of architecture. A few (like the one I mentioned) will be used in the first release in the 0.2.0 branch, and more will follow later.

Until then, use Code View for large files.

EDIT: Oh if current Sigil "stops responding" during the loading procedure, it's actually still doing work. Just let it finish, it will return GUI control when it's done.

thanks for the info Valloric. i'm glad to hear there are improvements in the work.

we appreciate your hard work :D

holy cow !! really ? zowie. that's very exciting. i can't wait to see what you've got in store for us in there...

It's merely an estimate. It could be sooner, it could be later. With software development, you never really know. :)

But that's the ballpark.

oh, yes, i understand you can't predict down to the day. but i'm impressed you're counting in weeks, and not in months. :)

I guess it's better not to mention Bookeen's past predictions :D

After looking at a WYSIWYG editor's output for awhile, you start to recognize what it is adding. At that point it generally becomes easier to type the info directly, rather than using the GUI interface.

Another tip for those having trouble with slow response times: It might help, at least while performing some of the initial layout, to break larger book projects into smaller pieces. Find an acceptable response rate, make your edits and save. Then merge all of the files together just before performing final conversion.

I've found it much faster to revert to an older release -- I'm using 0.1.4. That release is quite usable even for 2 or 3 megabyte epub files.

If you're reverting for speed, then use 0.1.5. It's the last release before Qt was updated in 0.1.6.