Talk:GSoC 2012 Ideas

From Scribus Wiki
Jump to navigation Jump to search

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