Question: What if *all* we did was make apps faster?

After Effects Steve Forde asks a provocative question:

What if we did NOTHING else in After Effects during 2014 other than make it faster? I mean MUCH faster. I mean much faster without a specific hardware requirement (new CPU, GPU, disk, machine, etc., etc.)?

To be frank, that’s not what’s in the works currently for 2014. A lot of our developer resources are going to focus on performance, but also on workflow and creative capability. I am curious though what your reaction would be if we ditched the workflow and creative stuff for 2014, and put ALL of our resources on nothing but making After Effects killer fast. Great!, good, bad, ugly?

What do you think?

My knee-jerk reaction is, “Of course, make everything faster!” How important that is, however, varies case by case. Do I need my iPhone to be faster—or would I trade away additional speed to get better battery life? And of course “faster” depends on much more than operations per second: I’d generally prefer an app that asks me to perform fewer steps en route to a result, even if those steps are a bit slower to calculate. Net performance depends on computer efficiency plus operator efficiency.

What are your thoughts & needs, app by app?

27 thoughts on “Question: What if *all* we did was make apps faster?

  1. IMHO, for apps like After Effects, Photoshop, and video editing and 3d animation apps, real-time feedback/rendering is the holy grail, in terms of speed.
    As a compositor, I dream of being able to work on a full HD project at full resolution with over 100 layers nested in multiple precomps, and dozens of effects, without ever having to render a preview.
    As a mograph designer, I’d want real-time full resolution playback for a comp full of 3d layers loaded with shape layers, .ai and .psd footage files, as well as zero-rendering for Cineware.
    I don’t know how this could be possible without some extreme GPU acceleration.

  2. I still see lots of room for improvement in Illustrator in terms of fundamental tool enhancements/additions (really, you guys could just buy Astute Graphics and integrate their features over a couple of years :D) but for apps like Photoshop and InDesign, AE, and Premiere Pro, code efficiency is one of those upgrades that has no learning curve!..

  3. Like speed but just love stability….
    Any news on Captivate? Please Adobe, stick Captivate into the Creative Cloud. It’ll blow Articulate out of the water if you do!
    Best Wishes

  4. Speed enhancements to AE would be wonderful.
    And with CC you at least don’t have to worry about no one upgrading because there aren’t any new features !!
    But for PS, ID, Ill, Acrobat, DW, etc, etc I don’t think speed upgrades are all that important (except maybe for some features like the new Smart Sharpen in PS and screen redraw in Ill to mention 2 I can think of now). For these apps I’d rather see bug fixes and new features.

  5. I’m not an AE user, but PS and the others have got to the point where there’s really not a lot of big new features they’re missing. I’d be all for some Snow Leopard-style releases that just make everything that’s there already, better.

  6. I look upon improved speed/performance as the #1 desired improvement with PS (which is my bread-and-butter app).
    I just got a new iMac (3.5 GHz i7, 32 GB RAM, NVIDIA GeForce GTX 780M 4GB GDDR5) and running PS CC is fantastic now, but would I love for it to be even faster/more powerful? Of course, without hesitation!
    In reality, there is probably no current level of speed and performance with which I won’t want an improvement with the new release cycle. =)

  7. AE could still use some usability improvements as well. A lot of time wasted for me is not really rendering, but actually getting to the settings I want to change. Compared to something like Flame (which admittedly focuses on productivity vs. being easy to learn and self-explanatory) or Nuke, the time spent managing windows and finding layers is quite a bottleneck as far as I am concearned. Then again, I only use After Effects occasionally, so some users may have developed workarounds that I am not aware of, but the existence of plugins like ft-toolbar and all sorts of layer taggers speaks volumes. Still, an 85%-of-the-work-done-is-performance year, sounds great to me.
    The application that really needs drastic speed improvements is Lightroom. But I am torn on this – there are so many issues and feature gaps with Lightroom that should have been fixed by version 2 that it is really hard to just say “go focus on speed”. There is still no real tablet workflow yet (the demos looked promising, but this could and should have been ready a few years ago), custom metadata fields still require writing plugins, and even then they only exist inside the database, there is no import/export for lists with image numbers to collections (I had to write my own python script that is sort of a hack using smart collection files), there is no way to create bézier masks for local corrections (requiring tedious paint jobs all the time, you’ve already got it working in SpeedGrade!), the raw converter still performs sub-par when handling images with very saturated colors (stage lights etc.), there are still no camera profiles for Fuji cameras to match their film simulation color presets, there is no face detection yet despite being heavily requested for many years, tethered shooting is still unreliable (though this may be the fault of camera manufacturers), some metadata fields are not available as search criteria (except for the unspecific “Text“ mode), testing seems to leave room for improvement (those bugs involving metadata fields when migrating catalogs and/or exporting files, like curves being ignored, keyword export status being reset really should have been caught in testing), virtual copies are still not written out to the XMP metadata, and so on.
    Don’t get me wrong, the team has always done and is still doing a stellar job on a very innovative product and we all appreciate the tireless effort they put into it , it just feels like they would need more resources from the company behind them so they don’t lag several years behind on some features and workflows that would seem like no-brainers.
    InDesign is fairly responsive at most things if files are kept at a reasonably small page count (using the book feature on large publications avoids most performance issues, even though the corresponding panel lacks a contextual menu, but that’s really a small thing), so speed is currently not much of an issue. This team should really focus on features as far as I am concerned, especially after the Cocoa conversion centric CC release cycle. Usable footnotes, color managing grayscale images (this is a should-have-been-in-version-1 feature), tables (sorting and reordering columns/rows, simple formulas), real support for multilingual documents (like proper support for Asian language typesetting inside the *regular* version), HTML5 export with liquid layout support, a simple command to split multi-column frames into individual ones, an animation timeline (something like the good old DHTML timeline in Dreamweaver) instead of unintuitive presets and panels settings that make things more complex than necessary in an attempt to make them easier, and so on.
    The Photoshop team has done a lot of great work lately, saving me a lot of time (background saving for instance is huge), even though I have to admit I am still pretty annoyed by the fact that they increased the GPU RAM requirements for the 3D features without communicating that properly, meaning that now I cannot use 3D at all on half of the Photoshop systems I have to use, and the computers are usually not even that old. A warning beforehand, or even an option to keep using the old version of the 3D plugin would really have been appreciated. The ideal solution would have been a fallback or a low resolution-only preview for textures above a certain resolution or something like that that would still keep it reasonably usable on an otherwise completely adequate 2008 laptop for instance. Or an option to “proceed at your own risk“. If I find the performance of a feature to be unacceptable for my particular use cases, I can always disable it myself. I’d rather make these choices myself than being locked out of something and not longer being able to edit my own documents. But I digress.
    I think the Photoshop team should split their work between adding useful features (3-Way Color Corrector, allowing the use Brush Tool presets as strokes for vector shapes, a Glyphs Panel, Lightbrush-style image decomposition, etc.), loads of small things (the selection mechanism from Hue/Saturation in Select Color Range, arbitrary number of subdivisions on Free Transfrom Warp, Sample All Layers option for the Patch tool, allowing the Gradient Overlay layer style to be applied per line of text/per character, support channels as displacement maps in the Displace filter, allowing us to use the Mac Ctrl-key in custom shortcuts like Ctrl+H, an “Add as Adjustment Layer“ checkbox in the Image > Adjustments > XXX dialog boxes in case something becomes unexpectedly complex and I change my mind mid-process and want an adjustment layer instead etc.), but mostly –let’s say two thirds of the budget – doing a lot of under the hood work modernizing the code to pave the way for the future. The ill-fated Cocoa transition is a testament to the fact that this is badly needed. Preventing future headaches should be the number 1 priority of any software project, and especially with a code base that has grown over so many years, a bit of maintenance would definitely benefit everyone. The CC subscription model is a great way to support that since you don’t have to sell a bunch of upgrades by cobbling together the Pattern Maker feature of the year to keep the marketing department happy. Supporting on-canvas filters was already a great first step. And the number of different slider widgets has been greatly reduced.

    1. Peter,
      Concerning: “I think that the Photoshop team should split their work between adding useful features … Lightbrush-style image decomposition … the Selection mechanism from Hue/Saturation in Select Color Range …”
      This is of interest to me, because I had a similar thought. And have done some work along a similar path, but just using Photoshop CC. In this case the newest version of Color Range already lets the user easily accomplish image decompositions based upon tonal segregations and the newest versions of the Maximum and Minimum Filters allow for more sensitive decomposition by simplifications. Plus, if the Camera Raw Filter is used in tandem with each of these, then all sorts of flexibility is at hand.
      I realize this won’t accomplish what Tandent aimed for with Lightbrush – however, the important “I’d generally prefer an app that asks me to perform fewer steps en route to a result” workflow objective can be satisfied.
      Do you have more specific ideas on what image decomposition should be on the route towards? That is, what types of effects or enhancements would you want to see in the final output(s)?

  8. Make it faster!!
    [Make what faster? (I’m trying to encourage thoughtful responses, not knee-jerk ones. Thanks to the folks who’ve already commented in detail.) –J.]

  9. “I’d generally prefer an app that asks me to perform fewer steps en route to a result” – Me too!!! AE is clunky and cumbersome, although that might be me, because I am not a full time mograph guy.

  10. I’m all in favor of speed improvements, especially for those of us without tricked out workstations…
    But… I have to finally ask this question of Adobe. Why is a 30º rotation (or pick a number), counterclockwise in Illustrator, clockwise in Photoshop, but counterclockwise in InDesign? Yikes!

  11. Getting Illustrator to 64 bit was kind of a revelation for doing very large outputs with complex transparencies. It was almost a life changing event to be no longer burdened by that 2G limit. I was so happy! Yet hardly anyone noticed because most people don’t make 20ft trade show displays.
    If After Effects could do realtime previews it would change the world. If Premiere could render out from and to any video format many times faster than real time it would be a revelation.
    It seems in the computing world we needlessly suffer for years. We also seem to get priorities mixup – We learn how to fly but our landing gear still have square wheels. Previews and Rendering is the Square Wheel. It may not be possible in 2014 or maybe even in this decade, but I would hope that it would be a #1 priority to eliminate.
    Recently Avid rewrote the industry standard multitrack recording software Pro Tools 11. This software is now performing many tasks many times more efficiently on the same hardware. They did add a few new important features, but almost all of them were productivity related. I think this is a prime example that good programming makes better software and sometimes you have to “rewrite” things from scratch to eliminate legacy bottlenecks.

  12. Back in the day we spent a fortune buying the ICE boards for AE to speed it up so we would always want it to run (render) faster. Though truthfully, no matter what you do, it will never run fast enough – give us 100 HD layers with effects and we will want 200! I also don’t think it is an either / or situation. In a post on the AE blog about things they want to implement in the next year there was an interesting comment that AEScripts already offers a lot of that functionality and gives users options. It is just not as convenient running scripts (have to go to the menu and scroll down and then it always seems to open an unneeded window when it runs). If Adobe could work with these developers to incorporate a lot of these solutions (I understand that cost could be an issue) they could devote more time to the speed issue and less time trying to find ways to add the create aspects (for instance I think that someone on the AE team is overthinking layer folders and tags – there are scripts for both, license them and give users both options and move on …) I don’t work for or know anyone at AEScripts BTW but do use A LOT of their scripts. There are very creative people out there – don’t reinvent the wheel.

  13. I print large files, and am still hoping that someday spooling can be in the background. We finally got background saves, but…
    and I have proposed a couple of ways that essentially accomplish by fudging this without a major rewrite (I presume 🙂

  14. I guess it comes down to: What do you mean by faster? Faster interactions? Faster render times? Or productivity enhancements? I don’t think anyone will ever say no to faster. I think the trick is finding out what faster means.
    [Exactly. –J.]
    For me as a motion designer, it means allowing me to design in the context of motion with fewer issues with bandwidth. These issues come from many different stimuli. Having to wait for RAM previews is a big one. Having to wait for 1 frame to update is a big one. But not being able to make adjustments to values in the contest of motion is probably where I lose the most time. There is a lot of guessing what I want a value to be. Only to guess again and again. And in that time I am also waiting for the 1 frame renders and the RAM previews, so those are part of that. My 2 cents.

  15. We have to deal with thousands of images and hundreds of movies every single day. Our team is used to do best in less time possible. Just like a production line on a factory.
    On Adobe apps, speed is vital for us but not only.
    For example, on Photoshop, each product we edit has 5 images. We must upload 1000 products every day. So to avoid a single click when using an app tool, means to avoid 5000 cliks on a day. To avoid a mouse drag = avoid 5000 mouse drags.
    That’s this the issue to improve for us.
    Not so important as mega-ultra-smart effects created by high qualified dev guys.
    The fact is that this simple and easy steps that could mean a lot to us, are generally not even considered by Adobe.
    For example:

  16. I think focusing on performance and stability for a sustained period would be a great idea for After Effects.
    While faster interaction should be a focus area, AE’s biggest performance disappointment has always been it’s multi-cpu utilization.
    The AE team advises users to experiment to find the right number of cores/ram for each project. The problem is, pros don’t have time to experiment to find the most efficient multi-cpu render settings for every project. If they did, they wouldn’t be concerned about rendering speed. The software should do that.
    Additionally, it takes AE quite a while to spin up the additional CPUs, and is known to hang when trying to startup via render queue.
    Worse, it occasionally simply cuts off a render to QT mid-render, *with no error message*, and moves on to the next queue item. That’s just too risky for a professional to deal with, so I just turn off multi-cpu rendering entirely, because I need to be confident my finished files are complete. That’s a huge waste on a 12 cpu system.
    So, yes. Optimize the code, get every module/effect multi-threaded, and make multi-cpu rendering intelligent and reliable.

  17. I’ll also just mention that from a faster *workflow* standpoint, the After Effects team’s agenda of pushing users away from the Render Queue to Adobe Media Encoder is bad for users.
    As it stands, AME renders far slower than After Effects. The other suggestion from the AE team is to render uncompressed intermediate files, then do a second encode pass in AME, setting up watch folders to automate it. This is adding a bunch of unnecessary additional steps and user interaction to the process.
    A user should be able to set up a render in AE, hit one button, and get the project renderered to the output format they need. End of story. No glacial AME renders, no intermediate files to track down and delete, no encode passes to set up, no watch folders to configure, no other user intervention period.
    Don’t get me wrong. I like AME, I think it’s a great utility to have for encoding existing files. I just don’t want it to suddenly become a giant speedbump on my way to the finished product I need.

  18. Lifhtroom would really benefit from significant attention from Adobe developers on speed and performance.

  19. Lightroom doesn`t even run what I would call perfectly smooth on my new 6 core Ivy-Bridge E. I`d really like the Lightroom team to ask that “speed question” to their users.

  20. With the years, we benefited from both enhancements in the code and the hardware we run the software on. I remember having to wait x minutes to run a simple Gaussian blur on an image. Back then, the “beep when done” option in the preferences was very useful. Nowadays, direct work with Photoshop is most of the times fast enough.
    The biggest pain point I feel when using it is when running batches, with actions, or simply image processor in Bridge. I wished several times to have a way to run multiple instances of Photoshop, to counter the fact that some operations cannot be multi-threaded, or to run Ps hosted ACR alongside Bridge hosted ACR in during a single batch, like the multiple parallel exports in Lr. Some reported fast jpeg exports in Bridge with the export to disk module, but it has been removed in CS6…
    Bridge also is seen by the public as a slow app because of its default settings, or some behaviors: given the fact that HiQ thumbnails appear one by one, I even thought that operation was not multi-threaded… (A way to use both instances of ACR would be good) I haven’t looked if it uses DNG smart previews ( I don’t think so) or even could share the ones from LR (avoiding to do the work twice)
    I am sometimes wary of editing metadata before thumbs are rendered. I, and others, should maybe start using embedded thumbs, do a first round of rejecting and captioning, while thumbs could be made in the background or at least not interfere with metadata entry.
    I know Lr does some of those faster, but I also deal with other files than just pictures, and I like the fact that it is a file browser.

Leave a Reply

Your email address will not be published. Required fields are marked *