[✓] Editor lags?

[Evo]

This ~2000 frame V6 trial lags badly for me in both Firefox and Chrome (for example when scrolling or creating a frame) and eats about 20% of my CPU, while this similarly long V5 trial works fine (but only in the V5 editor).
If you can't reproduce the problem, it might have to do with my computer not being the fastest ...

[GanonZD]

In fact, see this post by Unas. I think this means that Unas is actually dealing with this issue as we speak.

[Unas]

Yes, by the big change I'm working on I hope to hit two birds with one stone. The update I'm working on should decrease the CPU usage quite a lot overall, while probably increasing memory usage a bit.

Can you specify what kind of lags you notice most ?
Is it mostly that rows take some time to appear when you scroll ? (This should disappear with the change I'm making)
Or is it that the editor is slow to refresh when you add or delete frames ? (This should still happen a little bit, but hopefully less noticeable once I've done the proper optimisations)
Anything else ?

[Evo]

The most noticeable thing is that the scrolling doesn't look smooth, and when I scroll down by a large part, it takes a while until I can see anything. I'll look for anything else later.

[Unas]

I've just updated the site with a new version of the engine that powers the storyboard, following the principles I mentioned there.

It has a much bigger performance impact than I anticipated though, which is why it took so long : I had to do some pretty big cuts and optimisations to get reasonable performance out of this. Most notably, I've replaced the screen preview on each frame row by a much less precise one - loading the actual screen display engine for each row on a static page took ages...
And even with that, I'm not actually satisfied : the storyboard still takes too long to load the first time, and actually on my machine it feels rather slower than before (probably because it eats a very big lot of memory).

Anyway, for the moment I'd like your input : does the current update improve your experience at least a little bit ? There are still more optimisations coming, but I'd like to know if at least I'm on the right track or if I should just revert and think of something else.


FYI, I've also made it so that you can also use the old engine at will : you just have to append "&rs_engine=dynamic" to the editor URL.
Like :

Code: Select all

http://aceattorney.sparklin.org/V6_Test/editor.html?trial_id=<ID>&rs_engine=dynamic

Please all let me know what mode works best for you !
(In particular, Evo, please also try the old mode again using this parameter : it should also benefit from some of the optimisations I made, so perhaps it will have improved to the point where it feels smooth enough for you ?)


EDIT : Oh, and also, a small detail : with the new static engine, when you go back to the storyboard from another tab, it reopens in the place where you left.

[GanonZD]

My computer is definitely not the fastest in the market, but I would say that the new engine feels painfully slow. Every time you click on something, it takes about a second to react. I don't know how much the improvements are going to change, but as it is right now, I would definitely not like to be working on a long trial. That being said, I'm not an author, so my feeling is not what should count.

Scrolling does work much faster, though, and the grey screen that would temporarily appear whenever scrolling far up and down is totally gone. Thus getting an overview and quickly jumping back and forth is much easier. But in my POV, what really counts is the local feeling---that is, the feeling not when scrolling, but when editing, since this is definitely what is going to happen the most.

As mentioned, I look forward to the improvements, and I am optimistic that it might get better. But if it continues like this, I would at least give the author the choice of which system to use. Hey, people do have different PCs and different needs, so it would perhaps only feel natural to allow them to choose themselves in their settings. It's not easy to find one solution for everyone.

[Enthalpy]

It's a slight improvement for me. I tested on Phantasmagoria of Betrayal and found that the time it took for the editor to load decreased by five-ten seconds, but the time it took for the storyboard to load increased by about 50 the first time. A lot of this is due to Javascript scripts turning unresponsive. Granted, the parts of Phantasmagoria are about 3000 frames, so longer times are to be expected. However, the new engine allows for control+F searches, and scrolling no longer takes four-five seconds just to see if you scrolled to the right place, which roughly compensates for the 50 seconds. It takes about twenty seconds to get to the storyboard tab after the first time, but this is more than made up for by the "save scroll state" feature.

My preference is the new system, but if possible, I would like to see storyboard load times chopped down.

[Ferdielance]

I'm also getting "unresponsive Javascript" errors when I first open the Storyboard, but waiting for a while resolves them. Switching back and forth between "Sound" and "Storyboard" is pretty slow, as is switching from "Evidence" to "Storyboard." Here are the details of my testing:

Load times for Part 1 of Phantasmagoria of Betrayal in editor.

Browser: Firefox
OS: Windows 7
System Specs:
Intel Core i5-3210 2.50 GHz
6.00 GB RAM

Frame Count of Trial: 3791 frames, but many are small/empty.

Cache was cleared before attempting this.

Clicking on "Open in Editor" -> Display of profiles page: 12 seconds

First time clicking on Storyboard tab:

17 sec for storyboard to appear

Unresponsive script warning appears, clicking continue does nothing.

Wait a little

At 50 or so seconds from first click on Storyboard, clicking "Continue" allows me to continue.

Click on sounds - load is fairly quick.

Click on Storyboard again: 10 seconds to load.

Edit: A somewhat extreme suggestion:

What if there were a checkbox to "turn background/character preview off?" That is to say, by checking a box, you could make it so the editor didn't display the scenes at all, unless you clicked on them - maybe a text placename and character name would be shown instead. I imagine this would dramatically cut down the load times?

Another even more involved and convoluted solution would be to give authors the ability to do the following:

* Click on a frame number.

* Click on another frame number

* Click a "collapse frames" button and hide all the intervening frames until it's time to work on them again. At that point, clicking a little "expand" button would show them again.

This would mean that "collapsed" frames wouldn't need to be displayed, so giant trials could be edited and navigated quickly if the author just hid everything they weren't working on at the moment. When the storyboard was reloaded, it wouldn't need to actually display those frames.

That said, this sounds likely to generate a ton of "AAAAAH DID I JUST DELETE 1000 FRAMES???" complaints and comments.

(It would also mean that collapsed frames would have to be remembered between editing sessions, even if frames were added or deleted! This sounds like a delightful thing to arrange and test, and in no way contradicts how trial data are managed right now! NOPE)

[Unas]

I've just made a big update to the system that allows me to cut loading times AND restore the proper screen preview on all frames, all with a reasonable memory usage (hopefully).

Basically, the structure of all the rows is generated at once, but contains only the most basic information : the text, the "light" and imprecise screen preview, and the action. Thats all you need to know where you are when browsing quickly.
Then, when you stop scrolling, all the rows visible on screen get populated with the complete contents.

So, loading the storyboard the first time will still take a while for long trials, but hopefully a much shorter while than before - and because only visible rows are populated, the memory usage should be reasonable.

* Click a "collapse frames" button and hide all the intervening frames until it's time to work on them again. At that point, clicking a little "expand" button would show them again.

This would mean that "collapsed" frames wouldn't need to be displayed, so giant trials could be edited and navigated quickly if the author just hid everything they weren't working on at the moment. When the storyboard was reloaded, it wouldn't need to actually display those frames.

Actually, something of the kind is very likely to happen some day, the current engine could handle that well : it precisely does this kind of stuff for blocks like CEs and scenes where rows have to be hidden or displayed. But that would require a proper rethinking of the UI because as you say it could easily be confusing, so it'll come later.

[GanonZD]

Will it perhaps be possible to make the editor react faster? Whenever I click on or hover over something, it takes half a second to react, which is surprisingly frustrating. As mentioned, I do not have the fastest PC in the world, but I might not be the only one.

[Enthalpy]

I'm noticing a significant improvement with the revisions made. There's still some loading time, but the decrease in downtime is tremendous. There's still about thirty or forty seconds loading the storyboard the first time, but it's less than ten after that. Switching to other tabs is near instantaneous, although Ganon alluded to, hovering over things such as music and sound in Storyboard has half a second of lag that would be nice to remove if possible. But even then, that was around in v5 and the old system for v6.

I completely supporting the switch to the new system, as it is right now.

[E.D.Revolution]

The Editor is not lagging as much. I endorse this. The Player, however...

[Phantom]

Lags either way for me no matter if it's player or editor.

[Unas]

The Editor is not lagging as much. I endorse this. The Player, however...

Can you open a new topic and describe more specifically what lag you're talking about ?
- Do pictures take too long to appear in the top screen ?
- Are smooth transitions actually not so smooth ?
- Do CR element descriptions take long to appear when you hover them ?
- Does the editor freeze when running some actions ?
etc.
And on which trials you notice it most or least, as well.

Because as far as overall memory or CPU usage goes, V6 shouldn't be that much above V5. But some specific stuff might be improvable.

[drvonkitty]

I'm having some issues with the v6 editor after the most recent update. The new system is nice in that ctrl-f works, but almost every time I save my ~1000 frame trial, I get load times of about 25 seconds, which is a bit irritating - occurring everytime I save. There's also lag in general - when I click on things, there's a 1/2 to 1 second hang up that can be pretty irritating, as others have stated before. I didn't get it prior to this update.