Line delay

[EVANGELOS KARADIMAS]

Hi!

I started using opentoonz some months ago and I must say i really love the program. So, I decided to use it for a great project. 

But, there is a big problem I face and - as I can say- other users face it too. While drawing (in vector), I experience a great delay for the line to appear (and sometimes it does not appear at all). Has anyone solved the said problem?

Thank you!

OS. win10

OT version: 1.7.1

Gr.C.: AMD Radeon 7700 series

proc.: AMD Ryzen 3 1300

RAM 8GB

[OneWatt]

First, try turning "Accuracy = 100" and "Smooth=0" ... does this solve the delay issue?

If so, what's happening is that you're asking OT to perform some line-related functions (i.e., hand drawing-assist) that take processing time before you can see the results. 

In this case, it becomes a balance between how much smoothing and accuracy (vs what your hand actually produced) do  you want to be applied as opposed to how immediately do you want to see you lines drawn?

The more powerful your processor, the less of an issue this becomes. Let us know what you experience by playing with these parameters.

[EVANGELOS KARADIMAS]

Thank you OneWatt for replying!

Thought the change to the values did not make any difference, I disabled the "break" option next to them and I noticed a significant improvement, though I cannot say it solved the problem. But for sure, I can see the line appear quite sooner.

[OneWatt]

Glad to hear you've achieved some improvement. "Break" simply creates smaller sections of vectors along the way, rather than a single vector - so I'd be surprised if that would have much of any effect on delay if you hadn't told me it did.

I just tested on my OT setup (actually, Tahoma2D) and, to be honest, I cannot detect any difference in line timing of appearance with the "break" checkbox checked vs unchecked. Strange to me that you're getting an improvement, and that smooth and accuracy have no effect. This is markedly different than what most other users tend to experience.

Best wishes!  

[EVANGELOS KARADIMAS]

Thank you!

I'll keep on testing it to be sure disabling "Break" in deed improves functionality or it was just a coincidence  (there are a lot of vectors on that file, so perhaps that also causes an issue).

Since you mention Tahoma, I plan to test it at some point (I recently discovered it).

Thanks again for your help!

[OneWatt]

If you have a lot of vectors in the file, perhaps you're running light on RAM? (Turning on/off "break" only affects newly-drawn lines, not ones that already exist in the file.)

Can you can check how much of your 8 gb RAM is actually available while using OT? Perhaps you have other demands being placed on this shared resource?

[EVANGELOS KARADIMAS]

Oops, I thought I answered that. Sorry for the delay. I see that it takes about 250 MB more or less.

[OneWatt]

The real issue is how much memory is left (of your total 8 gig RAM)... 

When I run OT/Tahoma2D - before loading a scene file - I also consume about 250MB for the "empty" program. But after loading a reasonably complex animation scene, I can see another >3 GB consumed (of my total 16 gig). This leaves me with a lot less available processing memory than simply loading OT by itself with an empty scene.

And so if you're starting out with 8g of RAM and then loading a file with heavy vector math involved, you could be stretching the limits of your hardware - and hence the drawing delays.

What you're experiencing as delays aren't anything I see when I set those vector brush parameters as discussed above - even when a demanding scene is loaded. But then again, I'm using a Linux setup with twice the RAM. And Linux is gentler on memory consumption than Windows (or Mac) on any day, so even that isn't a fair direct comparison. 

In short, I suspect you may have a memory constraint created by the complexity of your scene design in t he context of Windows and 8gig with other competing apps underway?

Other trying the same scene out on a higher RAM machine, you should at least close down any other programs consuming memory that you don't need at the time, e.g., browsers, email, etc. See if that makes a difference in your available memory and/or OT performance.  

[EVANGELOS KARADIMAS]

Thank you OneWatt!

I'll describe the file I work on; it's a turnaround of a character. So, I usually draw it in one level and that's what I did here. I also work on other projects on opentoonz which are animated. There, I face no problems (at least when I dedicate each level to one character). So, my guess is that a temporary solution might be to draw each pose of the turnaround to a different level. Not the ideal solution, but it might make my life easier. It look as if a frame can not hold much "weight". I'll try it and I will let you know how it goes.

PS: No significant changes occur if I have some open programs at the same time. I do not know if I disable some of the running services might help (I'll check it some time in the near future).