`juce7` technical preview branch

My point was that it might be useful to point out that there already exists a good library for animation in JUCE in case anyone else reads this public thread.

Additionally, I thought it might spark some conversation about how the proposed JUCE animation classes differ from this existing library.

Fair enough! animator is pretty well-rounded, and is listed in the awesome-juce repository in case people want to explore any other solutions out there.

In terms of conversation about animations, what I’d ideally like to happen (at some point) is that designers would just design, and JUCE devs would just point code to the designs (and obviously tie the business logic).

That being said, it’d be nice to know what’s inbound because, with decent groundwork in place, I’m hoping there’s enough flexibility to bridge an animation solution to content from the liking of InVision or Figma. (All of which is possible… don’t ask me how!).

Anyway, I created an FR long ago to cover useful features off the top of my head: FR: Add Animation Support with Timeline Controls

1 Like

Looks like it’s pushed to master now, when can we buy it?

1 Like

You can buy it now!

6 Likes

The first step towards improving message-thread animations will be hooking up functionality similar to openGL’s setContinuousRepainting. This helps to avoid any redundant drawing, or skipped frames, caused by timers falling out of sync from a display’s FPS.

1 Like

You forgot to add LV2 to the README.md :#

Also worth updating the description on github :slight_smile:
image

RTAS LV2

2 Likes

Thanks for the mention @dave96 - I’m looking forward to seeing what’s in this branch and how it affects my little library.

2 Likes

We don’t have anything animation-specific published yet.

The initial JUCE 7 release contains the important groundwork on Windows, macOS and iOS, but it’s not yet accessible to users.

3 Likes

@drmr1 @ttg Thanks, we’ll get that fixed.

2 Likes

The first step towards improving message-thread animations will be hooking up functionality similar to openGL’s setContinuousRepainting. This helps to avoid any redundant drawing, or skipped frames, caused by timers falling out of sync from a display’s FPS.

Sure hope this will become true. One day.

The timing behavior was always very strange on Windows. It seems to fluctuate, even if called at a very high rate with correct delta time calculation.

One good example is the GraphicsDemo project. The one with the moving JUCE icon. If you turn off rotation, so it’s really just an image moving on float coordinates you will perceive micro stutter no matter what. Even with OpenGL and setContinousRepainting!

If you turn off the timer
startTimerHz (60);
and use

if (auto image = getCachedComponentImage())
  image->invalidateAll();

in GraphicsDemo::paint, it seems less noticeable, but it’s still there.

This is not a driver or Vsync issue, since a simple comparison with an JS + Canvas animation loop in any browser shows butter smooth movements. Tested the latest repaint consolidation stuff on JUCE 7 and unfortunately it didn’t change this behavior.

1 Like

This is my number 1 pet peeve with juce. I wrote a OpenGL vertex buffer style histogram to get around it. It’s when you touch the g.doStuff() commands that it starts. Doing stuff via native OpenGL while keeping to its thread is perfect, but that makes the entire graphics API in juce useless (in this context). Hope the new animation classes fix it!

Can we have the last “legal” commit which we’re allowed to access for Juce 6? thx

This is the most recent commit on the master branch before we bumped the version number to 7.

I’ve debugged these crashes a bit, but it’s quite difficult to see what’s going wrong as the crash is inside the pre-built (stripped) plugin binaries. I’ve also tried building the plugins from source, so that they retain debugging information, but wasn’t able to get very far. Building the plugins in an MSYS Mingw-w64 environment seems to dynamically link dependencies (cairo, pango etc.), and the UI can’t be loaded in the APH, even when I copy all of the DLL dependencies next to the running APH executable. @x42, please could you describe how the Windows build environment should be configured so that I can debug this further?

One clue, which may or may not be related: When opening and then exiting the AudioPluginHost with an instance of fil4.lv2, and with Application Verifier active, I see the following output in the debugger. This happens even if no editor window is opened - it’s triggered by just loading and then unloading the UI dll.

3b74:0e6c @ 01364875 - LdrpProcessDetachNode - INFO: Uninitializing DLL "C:\Program Files\Common Files\LV2\fil4.lv2\fil4UI_gl.dll" (Init routine: 00007FFE6B527530)
3b74:0e6c @ 01364875 - LdrpCallTlsInitializers - INFO: Calling TLS callback 00000000627F5FE0 for DLL "C:\Program Files\Common Files\LV2\fil4.lv2\fil4UI_gl.dll" at 00000000627C0000
3b74:0e6c @ 01364875 - LdrpCallTlsInitializers - INFO: Calling TLS callback 00000000627F5FB0 for DLL "C:\Program Files\Common Files\LV2\fil4.lv2\fil4UI_gl.dll" at 00000000627C0000


=======================================
VERIFIER STOP 0000000000000201: pid 0x3B74: Unloading DLL containing an active critical section. 

	0000000062DA73A0 : Critical section address. Run !cs -s <address> to get more information.
	0000022B5F50E060 : Critical section initialization stack trace. Run dps <address> to dump the stack trace.
	0000022B07E12FD6 : DLL name address.
	00000000627C0000 : DLL base address.