Onion Skin (Overlay) Problems

11 views
Skip to first unread message

Alan Nishioka

unread,
Aug 11, 2021, 11:09:06 AM8/11/21
to Entangle Development
First of all, great program.  I have been using it for the past week and it seems to to everything I want.  I had planned to add some features for my own use but discovered they already existed.

I am having trouble with the onion skin overlay.  It is very slow.  I am capturing 6000x4000 and it takes live preview several seconds to update, so this is painful to use.

I found 3 problems:
1. When it is drawing more that one overlay, it redraws the entire stack for each added overlay.  For example,. with 4 overlays, it first draws 1.  Then it draws 2 over 1.  Then it draws 3 over 2 over 1.  Then it draws 4 over 3 over 2 over 1.

i believe the fix is to remove the call to entangle_image_display_try_render_pixmap() from do_entangle_image_display_connect() in entangle-image-display.c

I think this is simply a bug and I can probably figure out how to do a pull request if you want.

2. The main problem is that all the overlays are resized to the first overlay and then composited together.  Since my files are 6000x4000, the pixmap is created in this size and everything is resized to match it.  This includes live preview which starts out at 480x320.  So just adding a single overlay makes the pixmap huge and significatly slows down the ui update loop.

I think the right way to handle this is to make the pixmap size based on the screen size.  I am not so familiar with gtk to know how to do this correctly.  Also, looking at the git log, it seems this was modified to work exactly this way.

3.  Currently, the onion skin code draws the first layer opaque (1.0 alpha), the middle layers at 0.3 alpha and the final layer at 0.65 alpha.  I think it should draw the first layer at 1.0 alpha and all the subsequent layers at 0.65 alpha (or a user defined value).  This creates an IIR (Infinite Impulse Response) filter giving lower layers exponentially less contribution to the final image.

Anyway, I think 1 is a bug, 2 should be done but I'm not sure how, and 3 is personal preference.

Thank you for all your work.

Daniel P. Berrange

unread,
Aug 12, 2021, 8:26:14 AM8/12/21
to Alan Nishioka, Entangle Development
On Wed, Aug 11, 2021 at 08:09:05AM -0700, Alan Nishioka wrote:
> First of all, great program. I have been using it for the past week and it
> seems to to everything I want. I had planned to add some features for my
> own use but discovered they already existed.
>
> I am having trouble with the onion skin overlay. It is very slow. I am
> capturing 6000x4000 and it takes live preview several seconds to update, so
> this is painful to use.

That's beyond painful - its completely unusable.

I've known it was slow,but my images are about 50% smaller in each
dimension, so 1/4 the pixel count.

> I found 3 problems:
> 1. When it is drawing more that one overlay, it redraws the entire stack
> for each added overlay. For example,. with 4 overlays, it first draws 1.
> Then it draws 2 over 1. Then it draws 3 over 2 over 1. Then it draws 4
> over 3 over 2 over 1.
>
> i believe the fix is to remove the call to
> entangle_image_display_try_render_pixmap() from
> do_entangle_image_display_connect() in entangle-image-display.c
>
> I think this is simply a bug and I can probably figure out how to do a pull
> request if you want.

I don't have time to examine the code right now, but if you think it
is wrong feel free to send a pull request and i'll review it then.


> 2. The main problem is that all the overlays are resized to the first
> overlay and then composited together. Since my files are 6000x4000, the
> pixmap is created in this size and everything is resized to match it. This
> includes live preview which starts out at 480x320. So just adding a single
> overlay makes the pixmap huge and significatly slows down the ui update
> loop.
>
> I think the right way to handle this is to make the pixmap size based on
> the screen size. I am not so familiar with gtk to know how to do this
> correctly. Also, looking at the git log, it seems this was modified to
> work exactly this way.

My rationale for rendering at full resolution is likely that I want
to avoid re-rendering the stack when the window size changes. As
you point out, this is probably optimizing the wrong criteria, as
speed of the live preview is more important here.

> 3. Currently, the onion skin code draws the first layer opaque (1.0
> alpha), the middle layers at 0.3 alpha and the final layer at 0.65 alpha.
> I think it should draw the first layer at 1.0 alpha and all the subsequent
> layers at 0.65 alpha (or a user defined value). This creates an IIR
> (Infinite Impulse Response) filter giving lower layers exponentially less
> contribution to the final image.
>
> Anyway, I think 1 is a bug, 2 should be done but I'm not sure how, and 3 is
> personal preference.

I don't have a strong opinion on 3 since I don't use it much myself, so
happy for any suggestions.


With regards,
Daniel
--
|: https://berrange.com -o- https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o- https://fstop138.berrange.com :|
|: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|

Reply all
Reply to author
Forward
0 new messages