This may’ve came up before but better speed/performance when hitting the play button to preview animations right within Hype maybe use safari as a preview engine if at all possible via clicking on preview which can play the animation in hypes artboard/stage.
Have you found a workaround for this problem?
From day one using Hype animations stutter, in between transitions It almost feels like why bother hitting that space bar at all, just preview in browser. I imagine the application playing everything with a great amount stress on memory, app…
Are there examples of other apps with this feature? Or, have you seen examples of this elsewhere on the web? (Please include a URL)
How high of a priority is this for you?
It just makes hype, hype? I guess - right now its hip not that hype? kidding.
[ ] Nice to Have
[ ] Impressionable (when others see hype in action not a browser preview)
[ ] Can’t use Hype without it
It actually is a sort of “Safari” that you are seeing. The stage is a WebKit instance only that it doesn’t have the same HTML structure while your editing (as seen in the screenshot). The preview is therefor currently actually different as it runs through the runtime and has the publicly known HTML output. In contrast, HTML on the stage is tailored to the editing experience and as a view for the IDE.
Cool, thanks for explaining the differences. I always thought that it runs a hybrid or something along those lines but not exactly. Would it makes sense to have the actual safari be on the stage as one of the options for the reasons mentioned?
Well it wouldn’t be Safari on stage as Safari is the Apple brand, services and “experience” wrapped around the webkit browser engine. Meaning you could create a webkit browser that runs the export but that wouldn’t be similar to the editor code as shown above. Hence, it would be a tabbed experience or some sort of forth and back between the two views. I am not sure if this makes so much more sense than just previewing it. One could maybe come up with something I guess but as of now that would always entail some sort of switch(ing).
An alternative I once thought about asking for in a feature request was live reload. So, some worker that runs in the background and publishes in a fixed interval without blocking or disrupting the editing experience (into a browser tab). But then again … every time you publish you destroy the “state”. Scenes, timelines and user interactions are reset’ed. So I am pretty sure that concept is not good for our current Hype and I refrained from publishing the idea.
Thanks for the feedback - I also am wanting to improve the editor animation playback performance.
While in the editor there’s a bit more for Hype to consider than the runtime, but the main performance issue is due to constantly updating the rest of the Hype user interface live (like the input fields, sliders, timeline cursor, etc.). There’s certain parts of updating and drawing that could use further performance work.
I have long considered having the possibility of the browser preview within Hype as well, as exiting out to a browser can be a small pain, especially if you use Chrome and it keeps making tabs. There’s pros and cons for this workflow, but mainly I haven’t fallen in love with any of the various ideas on how to do this from a UX standpoint (mostly the same issues @MaxZieb talks about!) .
