Hidden Hype Settings…

This is just a collection of conversations about terminal commands for additional Hype settings…

Don't resize new resources (images)…

defaults write com.tumult.Hype4 newResourcesAreSetToAutoResize -bool NO

Export with unminified code…

defaults write com.tumult.Hype4 UseFullHypeJSTemplate -bool YES

Don't check for updates…

defaults write com.tumult.Hype4 SUEnableAutomaticChecks -bool NO

Don't show welcome screen on launch…

defaults write com.tumult.Hype4 showWelcomeToHypeOnLaunch -bool NO

Enable Export Script Debug Logging…

defaults write com.tumult.Hype4 enableExportScriptDebugLogging -bool YES

Always Show Major Version Upgrade Warnings…

defaults write com.tumult.Hype4 AlwaysShowMajorVersionUpgradeWarnings -bool YES

Change Animated GIF Engine…

defaults write com.tumult.Hype4 AnimatedGIFEngine Apple


defaults delete com.tumult.Hype4 AnimatedGIFEngine

WebKit Developer Extras…

defaults write com.tumult.Hype4 WebKitDeveloperExtras -bool YES

Video Export Frame Delay…

defaults write com.tumult.Hype4 videoExportFrameDelay .5

WebKit Graphics Acceleration For Scene Editor

defaults write com.tumult.Hype4 useWebKitGraphicsAccelerationForSceneEditor -bool YES


Nice, some that I missed on the cookbook in there. Will update asap:


1 Like

I should mention that these are unsupported, are not guaranteed to work in future versions, and please use at your own risk. Also keep them in mind should you ever have problems -- for a lot of them there are very specific bugs that are tradeoffs in using them.


The list was updated based on the conversation about “Strange effects on MacBook Pro M3”.

Maybe I'm imagining things, but Hype seemed a lot… snappier …with WebKit graphics acceleration enabled. On my MacMini 2018, it really slows down when running a Hype project with too many elements. One of the reasons a recent template had 12 cards instead of 24 was that Hype was running too slowly with 24 cards. I just loaded up that template and it seemed OK.

Although, I tried revisiting one of the line drawing projects mentioned here… Adventures In Line Drawing …but it was still pretty laggy.

Maybe it was even worse than I remember. So, I turned off the setting, loaded up the card project again, and it was super laggy. WHEW! I turned the setting back on and Hype was nice and snappy again!

Why isn't that setting on all the time, or a toggle setting?

To clarify, I had actually used the wrong bool -- the default is YES, and to try to fix the bug, it should have been NO (the slower path).

It does not surprise me that with it off it is slower... I'll take a look at your document, it might be that I try another more targeted fix for the bug to try to preserve performance.

Does that mean you have the document, or does that mean you need the document? :thinking:

I assumed this was a document from one of your templates that would be accessible to download... but just so we're on the same page, can you please send me a zip of the document in question? Thanks!

Is there a secret setting to disable preloading of images by default?

Nope, this doesn't currently exist.

Can you elaborate on your needs? I could add one quickly that would be for any newly created images to have the setting of a hidden default.

The use case is that I mostly don’t use preloading and let the browser handle image loading…on some above the fold images I set preload (so, I would like to use it opt-in). This could also be a setting in the settings screen as it isn’t that obscure of a workflow and setting a conscious default is probably a good thing. A terminal default for now is fine, though.


The Hype loading bar is something of a throwback to the Flash days. Since it's not so easy to customize the loading screen — and since modern viewers generally dislike progress bars — my approach to Hype projects has been lightweight graphics… vectors, small images, or stuff that loads later.

So, when you really think about this issue, three things need to happen…

  1. Make it easier to customize the loading screen
  2. Setting to make the "preload" option disabled by default.
  3. Lazy-load setting for images. (No Internet Explorer means the support is excellent.)

I suppose Lazy Loading is already possible (natively with Hype) with custom attributes, but maybe that should be a checkbox? :man_shrugging:t2:


Here is a workaround to manage preloading on the fly:

It will be newResourcesAreSetToPreload in v4.1.17.

It has been often requested to be able to do per-scene loading granularity with the ability to make progress bars. I admit some of that is throwback to flash days, but still we can't necessarily rely on fast connections and being able to show some progress if scenes might get held up is going to be the way to go. I'd like users to be able to make their own loading/progress bars and just have some binding to hype's internal loading progress.

1 Like

I'm trying to imagine how that would work. Perhaps it's like this…

  • New Element — Loading Indicator (Settings to be displayed as Text or Progress Bar)
  • First Scene is Loading Scene — Document Setting (Checkbox)

Boom — no code solution

…or for those that code, maybe there's an API…

  • hypeDocument.percentLoaded

…then I could just toss that in a "while" loop and do whatever…

while (hypeDocument.percentLoaded <= 100) {

     // Stuff

     if (hypeDocument.percentLoaded == 100) {
          // Load next scene
1 Like


Requests for fine-grained preloading goes way back and we've accumulated a lot of information from users on all kinds of interesting control and display status. Suffice it to say, it unfortunately isn't quite as easy as boiling down to a percent :slight_smile:.

While we are at it, can we get a defaults to opt-out of images set to auto optimise by default.

Were I use code a lot this would be useful so I do not have to go through every image to turn it off.

The main issue is with file extensions.

3 posts were split to a new topic: Managing pointer events manually (ignore pointer events)

This currently exists as a hidden default:

defaults write com.tumult.Hype4 newResourcesAreSetToAutoResize -bool NO

At the very least we may automatically apply this for groups that have no events associated with them.


Doh.. :crazy_face: