View Single Post
Old 09-15-2009, 05:58 PM   #6
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,982
Karma: 350515
Join Date: Feb 2008
Device: Kobo Clara HD
Quote:
Originally Posted by Dave Berk View Post
That's fast! Seeing as it is marked as low priority (the ticket) I thought it would take much longer. Thanks!
The ticket is not the cause of the redesign (although I agree, I should create one for it). The cause is performance.

I was aware that I will probably have to write a CSS parser/rewriter and include it as an option on ebook imports with some sort of dialog when the user loads something in. Not something I looked forward to, but it would be necessary.

But what finally pushed me to decide to redesign the UI and the entire editing environment away from the One True Flow™ to one respectful of the original XHTML file arrangement in epubs is WebKit's abysmal performance with large flows. During Sigil's development, I failed to take into account all the various dreadfully coded HTML streams people would be importing. Of course, I took into account that people would be importing incorrect HTML (hence the integration of Tidy), but not stuff filled with flat-out useless junk. Just using sane HTML not only vastly improves CPU utilization but memory consumption too, as this thread illustrates.

I didn't fully consider the ramifications of that. Of course, during testing I mostly used my own, respectably coded ebooks. These worked fine. I also looked for badly coded ebooks, and while performance was lower, it all still worked respectably on my machine.

Then again, my main machine is a rather high-end quad-core with 8 GB of RAM. But even on my low-end five-year-old laptop the "bad" books could be edited rather nicely. But it seems I don't know just how bad "bad" can be. And from the reports, issue attachments and emails of users experiencing poor performance, "bad" can sometimes mean "really, really BAD".

And it's not like I can blame the WebKit devs. No browser is expected to perform well with files with 50k lines of XHTML, no matter the quality of the code. It's just not meant to.

So to improve performance, the redesign is necessary. I'm just saddened that I didn't realise this before the first release, because then you nice people wouldn't have to suffer through this. I still believe the One True Flow idea is nice for usability and user-friendliness, but alas, I'll just have to find a better way to achieve those goals.

The CSS issue will merely be fixed as a consequence of this new architecture, since styles will no longer conflict: flow-specific CSS will stay in those flows.
Valloric is offline   Reply With Quote