FYI, I'm still working on that problem - actually, I'm working on a big technical change to get rid of all the asynchronous / multi-thread stuff in this part of the editor. I expect today's browsers should enable me to get a reasonable performance without it, and it should avoid this problem.
However, to compensate for this change I have to make a lot of optimisations before the editor is really usable, so it'll take a few more days before the update is ready...
[Bug][E~P] Huge, HUGE bugs on the editor
Moderator: EN - Forum Moderators
- Enthalpy
- Community Manager
- Posts: 5172
- Joined: Wed Jan 04, 2012 4:40 am
- Gender: Male
- Spoken languages: English, limited Spanish
Re: [Bug][E~P] Huge, HUGE bugs on the editor
Will these optimizations and the loss of multi-threading have any other effects?
[D]isordered speech is not so much injury to the lips that give it forth, as to the disproportion and incoherence of things in themselves, so negligently expressed. ~ Ben Jonson
- Unas
- Admin / Site programmer
- Posts: 8850
- Joined: Tue Jul 10, 2007 4:43 pm
- Gender: Male
- Spoken languages: Français, English, Español
- Contact:
Re: [Bug][E~P] Huge, HUGE bugs on the editor
Well, it will only have effects on the process that refreshes the storyboard - my code is cleanly organised so the change won't affect anything else.
But with that change you should notice smoother scrolling as well.
Some technical stuff if you're interested :
In the current version, the storyboard generates only the rows around the visible area of the storyboard. When something changes (new frame, new block...) it only refreshes these rows around the visible area. These refreshes are handled asynchronously : updates to the storyboard are first computed in the thread, then the rows are displayed on the screen in any order (the visible ones first, and the one around afterwards, but a row displayed below another one could be generated before - it's not linear).
The advantage of that is that a change on the storyboard takes very little time to compute because there are only a few frames to rebuild. And because it's mostly asynchronous (a big part of the process is offloaded to the thread) you can still have a relatively smooth scrolling even though rows are being generated as you scroll.
The disadvantage is that, well, it introduces some synchronisation issues, and it can feel significantly slower on single-core CPUs, which can't optimise the use of this thread..
What I'm aiming at now is, on the contrary, to have the whole storyboard generated at once in a linear way.
If the browser can handle such a big page (recent browsers should be able to cope with it, hopefully), you can then scroll perfectly smoothly since there is no treatment to do when scrolling, and most synchronisation issues are no longer relevant. It should also be a little bit simpler for the browser to manage display because since the storyboard is built in a linear way, the rows are generated in the same order as they are displayed on screen.
This, I already have working on my dev version; however, it's hardly usable because each change requires rebuilding the whole storyboard. Imagine if you have a 7000 frames trial : inserting a new frame requires rebuilding thousands of rows, which causes your browser to freeze for a while... So the next step is to optimise that so that a storyboard change only refreshes the affected rows.
But with that change you should notice smoother scrolling as well.
Some technical stuff if you're interested :
In the current version, the storyboard generates only the rows around the visible area of the storyboard. When something changes (new frame, new block...) it only refreshes these rows around the visible area. These refreshes are handled asynchronously : updates to the storyboard are first computed in the thread, then the rows are displayed on the screen in any order (the visible ones first, and the one around afterwards, but a row displayed below another one could be generated before - it's not linear).
The advantage of that is that a change on the storyboard takes very little time to compute because there are only a few frames to rebuild. And because it's mostly asynchronous (a big part of the process is offloaded to the thread) you can still have a relatively smooth scrolling even though rows are being generated as you scroll.
The disadvantage is that, well, it introduces some synchronisation issues, and it can feel significantly slower on single-core CPUs, which can't optimise the use of this thread..
What I'm aiming at now is, on the contrary, to have the whole storyboard generated at once in a linear way.
If the browser can handle such a big page (recent browsers should be able to cope with it, hopefully), you can then scroll perfectly smoothly since there is no treatment to do when scrolling, and most synchronisation issues are no longer relevant. It should also be a little bit simpler for the browser to manage display because since the storyboard is built in a linear way, the rows are generated in the same order as they are displayed on screen.
This, I already have working on my dev version; however, it's hardly usable because each change requires rebuilding the whole storyboard. Imagine if you have a 7000 frames trial : inserting a new frame requires rebuilding thousands of rows, which causes your browser to freeze for a while... So the next step is to optimise that so that a storyboard change only refreshes the affected rows.
- Unas
- Admin / Site programmer
- Posts: 8850
- Joined: Tue Jul 10, 2007 4:43 pm
- Gender: Male
- Spoken languages: Français, English, Español
- Contact:
Re: [Bug][E~P] Huge, HUGE bugs on the editor
As mentioned here, I've just updated the engine that powers the storyboard tab.
Because it's now completely synchronous (there is no parallel thread anymore), you being faster than the machine shouldn't cause any problem.
However, I did have to change a little more than expected... and I might have introduced some bugs. Hopefully I didn't make big mistakes, but if you notice similar errors (frames with weird system actions that show up; incorrect frame that is added/deleted, etc) let me know.
Because it's now completely synchronous (there is no parallel thread anymore), you being faster than the machine shouldn't cause any problem.
However, I did have to change a little more than expected... and I might have introduced some bugs. Hopefully I didn't make big mistakes, but if you notice similar errors (frames with weird system actions that show up; incorrect frame that is added/deleted, etc) let me know.
- Enthalpy
- Community Manager
- Posts: 5172
- Joined: Wed Jan 04, 2012 4:40 am
- Gender: Male
- Spoken languages: English, limited Spanish
Re: [Bug][E~P] Huge, HUGE bugs on the editor
Is this bug considered fixed?
Unas fixed a possible cause, so I'm not quite sure if this qualifies.
Unas fixed a possible cause, so I'm not quite sure if this qualifies.
[D]isordered speech is not so much injury to the lips that give it forth, as to the disproportion and incoherence of things in themselves, so negligently expressed. ~ Ben Jonson
- Unas
- Admin / Site programmer
- Posts: 8850
- Joined: Tue Jul 10, 2007 4:43 pm
- Gender: Male
- Spoken languages: Français, English, Español
- Contact:
Re: [Bug][E~P] Huge, HUGE bugs on the editor
If I keep the new engine I presented at http://aceattorney.sparklin.org/forum/v ... 26#p670126 , then this bug will be fixed.
- E.D.Revolution
- Posts: 5743
- Joined: Mon Jul 26, 2010 9:00 pm
- Gender: Male
- Spoken languages: English and decent Spanish
- Location: Across dimensions, transcending universes
Re: [Bug][E~P] Huge, HUGE bugs on the editor
Hmm. Well, I'm not getting those weird bugs.
Editor-wise, it seems that the editor can lag quite a bit, especially on dropdown menus. Sometimes I click on a dropdown menu and it goes blank. I'd have to click on something else to reset it. Now imagine if a user wants to do a lot of once and is slowed down considerably because of this.
Player-wise, while everything else on the Editor is set correctly, the Player can lag in loading up the particular frame. So for some dirty tricky to "hiding" stuff, the popup doens't load fast enough to hide such stuff.
Editor-wise, it seems that the editor can lag quite a bit, especially on dropdown menus. Sometimes I click on a dropdown menu and it goes blank. I'd have to click on something else to reset it. Now imagine if a user wants to do a lot of once and is slowed down considerably because of this.
Player-wise, while everything else on the Editor is set correctly, the Player can lag in loading up the particular frame. So for some dirty tricky to "hiding" stuff, the popup doens't load fast enough to hide such stuff.
- Enthalpy
- Community Manager
- Posts: 5172
- Joined: Wed Jan 04, 2012 4:40 am
- Gender: Male
- Spoken languages: English, limited Spanish
Re: [Bug][E~P] Huge, HUGE bugs on the editor
Do you still observe this one? I'm not able to reproduce it.E.D.Revolution wrote:Editor-wise, it seems that the editor can lag quite a bit, especially on dropdown menus. Sometimes I click on a dropdown menu and it goes blank. I'd have to click on something else to reset it. Now imagine if a user wants to do a lot of once and is slowed down considerably because of this.
[D]isordered speech is not so much injury to the lips that give it forth, as to the disproportion and incoherence of things in themselves, so negligently expressed. ~ Ben Jonson