[Okular-devel] Redrawing the screen due to optional content group changes

[Albert Astals Cid]

El Dilluns, 20 de juliol de 2015, a les 15:26:42, Jeremy Maitin-Shepard va 
escriure:
> On Sat, Jul 18, 2015 at 7:27 AM, Albert Astals Cid <aacid at kde.org> wrote:
> > El Divendres, 17 de juliol de 2015, a les 12:52:30, Jeremy Maitin-Shepard
> > va
> > 
> > escriure:
> > > Forwarding to the list, since I sent my original reply incorrectly...
> > > 
> > > On Fri, Jul 17, 2015 at 12:51 PM, Jeremy Maitin-Shepard <
> > 
> > jeremy at jeremyms.com
> > 
> > > > wrote:
> > > > 
> > > > On Thu, Jul 16, 2015 at 3:16 PM, Albert Astals Cid <aacid at kde.org>
> > 
> > wrote:
> > > > [snip]
> > > > 
> > > >> > Any advice about how to deal with this redraw problem?
> > > >> 
> > > >> Trigger the redraw yourself? See Saheeb's branch for optinal content
> > > >> (origin/gsoc2015_layer_feature), I'd say it probably makes sense for
> > 
> > you
> > 
> > > >> to
> > > >> base your work on his branch.
> > > > 
> > > > Thanks, I'll take a look.
> 
> I see that the gsoc2015_layer_feature branch just triggers a redraw of
> every page in the document any time there is any change to optional content
> group visibility.  Merging my changes on top of this branch indeed makes
> the animation kind of work.  However, there are some serious performance
> issues.  Redrawing the whole document for each frame of the animation kills
> performance if there are many pages.  To avoid this though would seem to
> require poppler providing an interface for determining which pages are
> affected by each optional content group.  

That'd be ideal, yes.

> (This is needed for a proper
> implementation of the Javascript OCG interface anyway.)  Alternatively a
> hack might be to redraw only the current page; not sure how this would
> interoperate with the layer panel.
> 
> Even in single page documents, though, redrawing the whole page is often
> too slow to achieve reasonable frame rate.  Somehow acrobat reader is
> significantly faster.  It would be nice if there were a way to prerender
> each optional content group individually so that toggling the visibility
> wouldn't require rerendering.

That's another option, though it probably increses considerably the memory 
usage it's worth exploring.

Cheers,
  Albert