Proper Rendering Design: Division of Labor

[Voice303]

Hi everyone,

I have designed a canvas object that represents a clip launcher grid (think Ableton Live, Bitwig Studio, etc) I find myself often running into script size limitations in my "On Redraw" handler code because that is where ALL of my drawing code is. I even had to create a script minifier to fit my code into Lemur. I have my script running On Demand so performance is not a huge issue, just fitting everything in one script is!

Would a better design be to draw everything one time in my Init function based on initial state and then draw things in my OSC message handler as needed?

In the case this is true, is the "On Redraw" handler actually only for handling things that need to be redrawn with every frame?

Thanks,

Voice303

[ndivuyo]

Yeah you'll want your 'On redraw' script to execute the various drawing scripts. You can have them on 'Manual' and then recall them in the 'On Redraw' script. Also you can create custom scripts that have a shape ready and then just input the arguments
ex : circle(c,x,y,r,start,end,ccw);

Definitely have things drawing 'on demand' and refresh the canvas where neccessary.

Also it you recall multiple Manual drawings, make sure the canvas is cleared before hand and then use canvas_save() and canvas_restore() at the beginning and end of your scripts so they are not wiped and kept individual

[Macciza]

Have a look through he Canvas Tips and Tricks thread above . . .
And do a net search on Canvas performance techniques...

Yes it will be far more efficient to draw static stuff only once rather then continually redrawing it . . .
Only redrawing elements which have changed will be more efficient ...

[Voice303]

Have a look through he Canvas Tips and Tricks thread above . . .
And do a net search on Canvas performance techniques...

Yes it will be far more efficient to draw static stuff only once rather then continually redrawing it . . .
Only redrawing elements which have changed will be more efficient ...

Thanks, actually I did look through your thread as well as a few example projects but it still wasn't totally clear how everything was separated.

I implemented a "per object" rendering that keeps track of when a specific part of the screens needs to be rendered after a change. Basically I have an array for each part of the screen that can change and scan through it when On Redraw is called and look to see specifically what needs to be rendered.

Beyond that I split my On Redraw function into 3 different functions to redraw certain parts of the UI so now my code size is managable.

So On Redraw now calls draw_clips(), draw_scenelauncher() and draw_tracks() which draw their specific part of the system on load and when something is changed.

Thanks for the help guys.

[Macciza]

As the Canvas is a web technology you can find and apply recommendations for better web performance ....

One thing that may be relevant is the avoidance of 'state' changing too much ie continually changing colors whilst rendering. If possible do all the rendering for a particular color , then all of another color, rather then chopping and changing as you go.

Bit hard to give any finer recommendations without more info

[Voice303]

As the Canvas is a web technology you can find and apply recommendations for better web performance ....

One thing that may be relevant is the avoidance of 'state' changing too much ie continually changing colors whilst rendering. If possible do all the rendering for a particular color , then all of another color, rather then chopping and changing as you go.

Bit hard to give any finer recommendations without more info

There is very little redrawing that happens. If the user adds a clip, changes a tracks color, a clips color, a track name, clip name, or the playback state for a track changes the individual object is marked for rendering.

This doesn't even happen once a second on average so I don't need to worry about further optimizations to rendering code until I go to implement things like drag and drop / animations.