Talk:GSoC 2012 Ideas: Difference between revisions

From Scribus Wiki
Jump to navigation Jump to search
(-- ~~~~)
 
No edit summary
Line 29: Line 29:


<Velmont> :-)
<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)

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)