[Valloric]

Originally Posted by KevinH

Hi,

I am a Mac user.

Yes, I am seeing the same thing.

First of all, thanks Kevin for your input. I really appreciate it.

Originally Posted by KevinH

- searching (only in 0.1.5) seemed to bring it to its knees when in the book view.

Unfortunately, searching in Book View is slower. Mostly because I have to use javascript to make this work... and I have to parse in the whole doc to a separate DOM implementation to work around Webkit's bugs and inconsistencies, and to enable interoperation between C++ code and JS.

Qt 4.6 will bring a new QWebElement API to their Webkit integration, and that will enable direct manipulation of the internal DOM. The Book View search back-end will be rewritten when this hits.

But even now, it shouldn't bring it to its knees. Currently, on a fairly large book, the Book View search lag time for a very rare term is 10ms. This is on Win7 x64, on a 4 years old system. Why is it taking so long on Macs, I don't know... but I'll have to find out.

Originally Posted by KevinH

- Anytime I close the ToC editor, I seem to wait and watch the ball spinning for quite some time.

TOC editor updates the whole document, which makes Webkit reload the whole flow. One more thing that will be remedied with 0.2.0, when the flows will be much smaller (and so will the reload lag).

Then again, there has to be a way to make TOC edits update only the required portions... and there is. I'll rewrite the TOC updating when QWebElement arrives. This issue should then go away for all platforms.

But on Windows, current TOC updating takes about a few seconds. Too long, but it should still be somewhat tolerable. I don't know how it behaves on Macs.

Originally Posted by KevinH

- simple book view window operations (growing, shrinking, etc) are so slow that resizing the window at all is problematic when you have a full size book loaded.

This is universally slow on all platforms. It's Webkit trying to reflow the whole book while you are resizing it. I've been trying to force it to delay this reflow until the resize operation is complete, but with little luck because I'm trying to maintain compatibility with vanilla Qt, and this means not rewriting core components.

I've become pissed off enough to decide to finally split from vanilla Qt upon their next release. I have enough bugs of my own without having to bear theirs.

Originally Posted by KevinH

Of course, most of this was true with 0.1.4 when loaded with a full sized book, but it does seem slower.

I have no idea why this is happening on Macs. Performance should be better with 0.1.5., and on Windows and Linux it is. And that's not a subjective opinion, it's backed up by two different code profilers. Admittedly, I haven't tested it on Macs, for already mentioned reasons.

This is incredibly frustrating.

Originally Posted by KevinH

I have taken to working in code view only, and when I want to see what it looks like, I save it as an sgf, unzip the sgf and load the html file in Safari which allows me to resize, scroll, etc quite quickly (but of course all editing then has to be done in code view - which kind of defeats the purpose).

Aaaaah... this is horrible. I can't suggest anything but to wait until I sort this out. That may take some time... sadly.