Talk:GSoC 2012 Ideas: Difference between revisions
No edit summary |
No edit summary |
||
Line 33: | Line 33: | ||
In this discussion, Cz mentionned things he think can use pararel code: | In this discussion, Cz mentionned things he think can use pararel code: | ||
* DocumentChecker (specialy for checking for issues in text frames) | |||
* relayouting whole document after doc->invalidateAll | |||
* relayouting visible area in low zoom level (multiple pages visible) | |||
* (I am not sure) drawing text frames (after layouting glyphs have fixed x,y coords - right? if so then few lines can be drawed at once) | |||
* output/printing | |||
* image effects | |||
* and in the future if these features will be implemented: search&replace for whole document & updating markers (specialy notes) |
Latest revision as of 20:52, 16 March 2012
-- Ale 17:58, 14 March 2012 (CET)
#3 Rendering and multithreading
<Velmont> Hmmm. Anything else... -- Oh, yeah, it's actually nice and speedy. But a toggle from display to the other mode is very very slow. I was doing quite a few toggles because the editor was working in the same room and always coming over :P
<a-l-e> do you mean togling between preview and edit mode?
<Velmont> a-l-e: preview and edit, yes.
<a-l-e> i wonder if there is a reason for this switch to be slow... for what i know about scribus, i guess that it's redrawing all the pages and not only the ones shown on screen...
<Velmont> a-l-e: Seems maybe scribus is caching loads of stuff and thus is fast when you're in the mode, - but switching, it throws away everything. You probably can't switch back to the old one either, because it might be out of date.
<a-l-e> would be nice to know the reasons why it slows down...
<Velmont> Hmmm. Although it could maybe just switch to the old cached version, then show a progress indicator on that page (or gray it a little) to show that it's old and stale, -- then update that page, and on finished, switch from the old-cached-preview to the new-preview. That way it could also paint only one or two pages (quite possibly the only ones you've changed), and very quickly show the whole document.
<a-l-e> imo a good place to do the first tries with some multithreading :-)
<Velmont> Or, -- no, if there is a "dirty" marker on each page. -- Maybe (I don't know anything about scribus internals), it could only re-render the changed pages. So you have a cache, -- and in the usual case of preview, change around do some more stuff on two pages (out of 50), and new preview, only 2 pages are dirty, so it only re-renders those, and uses the old for the others.
<Velmont> Anyway, -- I'm actually really happy with Scribus' speed in normal work. -- When it has switched, it's very nice and snappy.
<a-l-e> there is a potential gsoc student interested in multi threading... i wonder if this could be a project for him... not an easy one, though... it would be nice to hear from the team if they think it's doable...
<Velmont> :-)
See also discussion on main list : http://lists.scribus.net/pipermail/scribus-dev/2012-March/001501.html
In this discussion, Cz mentionned things he think can use pararel code:
- DocumentChecker (specialy for checking for issues in text frames)
- relayouting whole document after doc->invalidateAll
- relayouting visible area in low zoom level (multiple pages visible)
- (I am not sure) drawing text frames (after layouting glyphs have fixed x,y coords - right? if so then few lines can be drawed at once)
- output/printing
- image effects
- and in the future if these features will be implemented: search&replace for whole document & updating markers (specialy notes)